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SIMULATION NEWS 


Now-SIMSCRIPT II.5 reduces the cost 



of simulation by 75% 

You get results sooner and they are better understood 
Before After 


SIMSCRIPTI 1.5—simplifies and reduces costs 


special offer—free trial and training 


S IMSCRIPT II.5 gives you 
a compact, English-like 
language that helps you succeed 
by saving your organization lots of 
money. 

Your simulation program is 
75% smaller and reads like a 
description of the system you are 
studying. Your model develop¬ 
ment, checkout, modification and 
enhancement are greatly 
simplified. 

Widely used and fully supported 
SIMSCRIPT II.5 is a well es¬ 
tablished, standardized, and widely 
used language with proven soft¬ 
ware support. 

Typical applications include: 
military planning, manufacturing, 
communications, logistics, and 
transportation. 

These are complex systems and 
yet, you need to provide results in 
a timely manner. 

With SIMSCRIPT II.5 you get 
results sooner and they are better 
understood. 


Computers with SIMSCRIPT II.5 

• IBM AT, XT or compatible. 

• Most Mainframe computer 
types including IBM, CDC, VAX, 
Univac, Gould, Prime, Data 
General and Cyber 205. 

Sun and Cray SIMSCRIPT II.5 
are under development. 

Free trial and special offer 

The free trial contains every¬ 
thing you need to try SIM¬ 
SCRIPT II.5® on your own com¬ 
puter. 

We send you SIMSCRIPT II.5, 
sample models, and complete 
documentation. You can build 
your own model or modify one 
of ours. If you have questions, 
just call us for an immediate 
response. No cost or obligation. 

For a limited time we will also 
include free training. 

For immediate information 

Call Hal Duncan at (619) 
457-9681. In the U.K. call Steve 
Wombell at (01) 940-3606. 


Rush information on 
I SIMSCRIPT II.5 free trial 
and special training offer 

Free trial-learn the reasons for the 
broad and growing popularity of 
I SIMSCRIPT II.5. Try SIMSCRIPT 
II.5, user instructions, training, 
documentation, and user support—no 
cost or obligation. 

I Special offer-return the coupon today 
I and you will be eligible for free training. 



Telephone 




Return to: 

CACI 

3344 North Torrey Pines Court 
I La Jolla, California 92037 
I or better yet, call Hal Duncan 
I at (619) 457-9681 
In the U.K. 

CACI 

I 26 The Quadrant 

Richmond, Surrey, England TW9 IDL 
Call Steve Wombell at (01) 940-3606 


©1986 CACI, INC.-FEDERAL 
SIMSCRIPT II.5 is a registered trademark and 
service mark of CACI, INC.-FEDERAL 
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Guest Editors’ Introduction: 

The Federal Aviation Administration’s Advanced Automation Program 

Valerio R. Hunt and Gregory V. Kloster 

Engineering the world’s largest command and control system is a complex undertaking. This issue communicates the authors 
experiences in the design of the next-generation air traffic control system. 

The FAA’s Advanced Automation System: 

Strategies for Future Air Traffic Control Systems 

Valerio R. Hunt and Andres Zellweger 

The FAA’s new-technology air traffic control computer system will lead to highly automated air traffic control by the turn of 
the century. 

Evaluating Proposed Architectures for the FAA’s Advanced Automation 
System 

Jean-Marc Garot, Delbert Weathers, and Thomas Hawker 
Complex system-architecture evaluation is a business fraught with many perils. 

The FAA seeks to minimize these perils by pursuing a broad range of architectural analyses. 

Engineering the Man-Machine Interface for Air Traffic Control 

Gregory V. Kloster and Andres Zellweger 

Commitment to MMI concerns is an integral part of the FAA’s Advanced Automation Program. From day one the controller 
has been an active participant in a rigorous MMI design process. 

The Quantification of Operational Suitahility 

Mark D. Phillips 

A team of air traffic controllers has participated in a structured requirements engineering and design evaluation process to 
help develop the Advanced Automation System computer-human interface. 

Capacity Management of Air Traffic Control Computer Systems 

Sandra Bleistein, Robert Goettge, Frank Petroski, and Robert Wiseman 
Detailed workload specification, extensive response time requirements, and precise modeling of software behavior characterize 
capacity management of these complex, embedded computer systems. 

On the Achievement of a Highly Dependable and Fault-Tolerant Air Traffic 
Control System 

Algirdas Avizienis and Danforth E. Ball 

Can we trust the new AAS to deliver highly dependable air traffic control service until the year 2000? Yes, systematic 
application of fault tolerance offers a solid promise of success. 
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Modeling and Managing CAD Databases 

Mohammad A. Ketabchi and Valdis Berzins 


Although designers rarely pay much attention to data management, an 
requirements of the design process—could increase their productivity. 


effective DBMS—one 


that meets the modeling 
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An AI Productivity 

Announcing TFs Third Artificial Intelligence 


T 1. . J ) , Hj. 1 7 T n this new symposium, a round- 

Lcctding experts cxciTniTie today s proptoule I sQ^e of the world’s fore- 

applications and tomorrow s opportunities ... ^ most authorities wiii explore 

111 1 ^77 ^ today’s productivity benefits and tomor-l 

for Icnowlea^e-'based systems, natural lan^ua^e row’s potentials of mpidiy spreading 

processing and rapid prototyping of Al and technologies at the leading edge of ai. 

conventional software. 





Roundtable 

Satellite Symposium. April 8,1987 



At no charge from TI, you can bring 
these valuable perspectives right into 
your own auditorium or conference 
room. It’s for everyone interested in 
multiplying human productivity— 
and, its also a chance to get all of your 


people up to speed together. 

More than 85,000 managers, tech¬ 
nologists, educators and students par¬ 
ticipated in TI’s first two AI satellite 
symposia. 

Even with this broad, diverse audi¬ 
ence, 98.3% expressed interest in at¬ 
tending another—strong testimony 
to value and relevance! 

In four hours. Symposium III will 
examine the very latest developments, 
applications and future pxatential—from 
diverse perspectives. It will broaden the 
view of AI beyond knowledge-based sys¬ 
tems to also include natural language 
processing and rapid prototyping of both 
AI and conventional software. 

And, following Symposium III— 
after an hour break—we will broadcast, 
for those who missed Symposium II 
(Knowledge-Based-Systems: A Step-by- 
Step Guide to Getting Started), a 90- 
minute condensation packed with useful 
direction on how to get started with 
knowledge-based systems. 

j Feigerdnum. Heilmekr. Kay. Lenat. | 
i Martm Scfumk. Schorr. Tennant. \ 

An exceptional panel brings 
you the latest perspectives on AI, 
present and future: 

Or. Edward A. Feigenbaum, AI pio¬ 
neer, author and lecturer, renowned 
educator from Stanford, past president 
of the American Association of 
Artificial Intelligence. 

Eh. George Heilmeier, Senior Vice 
President and Chief Technical Officer 
of Texas Instruments, former Director 
of the Defense Advanced Research 
Projects Agency (DARPA). 

Dr. Alan C. Kay, Apple Fellow, 
pioneer and key innovator in personal 
computing and artificial intelligence. 
Invented “Smalltalk” computer lan¬ 
guage and pioneered the use of icons. 

Dr. Douglas B. Lenat, Principal 
Scientist for Microelectronics and 
Computer Technology Corporation 


(MCC), pioneer in machine learning 
through study of the nature of heuristics. 

Dr. Roger C. Schank, Professor of 
Computer Science and Psychology, Yale 
University, and Chairman of Cognitive 
Systems, Inc. Pioneer in development 
of computer models of memory and 
learning. 

Dr. Herbert Schorr, Group Director 
of Products and Technology, IBM. 
Responsible for the introduction of new, 
advanced technology and applications. 

Dr. Harry R. Tenmnt, roundtable 
host. Senior Member Technical Staff 
and Manager of AI Research in Texas 
Instruments Computer Science Labora¬ 
tory. Inventor of the concept of menu- 
based natural language understanding. 

Plus a special interview with: 

James Martin, author of 33 books on 
computing technology and one of the 
computer industry’s best attended lec¬ 
turers. Chairman of James Martin 
Associates, and Knowledge Ware. On 
technical advisory board of Teknow- 
ledge and the Artificial Intelligence 
Girptt ration. 

Bringing this AI symposium into your 
facilities is easy and inexpensive. 

More than 1000 sites in North 
America and Europe downlinked our 
last symposium. It’s neither difficult 
nor expensive. All you need is a satel¬ 
lite dish and TV monitors. If you’re 
not already equipped, everything you 
need can be rented for about $1,500. 
We’ll tell you how. Simply write Texas 
Instruments, AI Symposium, RO. 

Box 181153, Austin, TX 78718 or call: 
1-800-527-3500 

Texas 

Instruments 





IHTERS TO THE EDITOR 


Pamas: SDI “red herrings” miss the boat 


To the editor: 

From its title, “Can software for the 
Strategic Defense Initiative ever be error 
free?” to its conclusion, “...the shield 
will leak,” Ware Myers’s article in the 
November 1986 Cow/jMter discusses red 
herrings as if they were real issues. Such 
articles help SDI supporters to distract 
the public from what SDI critics, such as 
myself, are really saying. 

The observation that the software 
would not be error free or perfect is 
trivial. The software that I use to write 
this letter is not error free but is ob¬ 
viously useful. No serious critic based 
his statements on an assumption that 
perfection was required. A statement 
about “error free” software does appear 
in the unclassified portion of the 
Fletcher Report. One SDI officer claims 
to have written those words while drunk. 

As one who is familiar with some of 
the military software that the US now 
uses, I never would seriously consider re¬ 
quiring that SDI be “leak-proof” under 
all circumstances. I don’t even expect 
that of my raincoat. President Reagan is 
said to make such statements, but no ex¬ 
perienced engineer takes them seriously. 
Phrases such as “perfection,” “leak- 
proof,” and “Astrodome” have been 
introduced into the discussion by SDI 
supporters. 

We all know that weapons, like other 
tools, don’t have to be perfect to be 
useful. The arguments used by SDI sup¬ 
porters allow one to conclude that, for 
any value of N, a shield with an effec¬ 
tiveness of N percent would be useful. 
For example, a partially effective shield 
could provide strategic parity or superi¬ 
ority even if the other side has more 
warheads. Many engineers working on 
SDI have substituted such goals for 
President Reagan’s. 

However, such arguments are based 
on the assumption that we know, with 
reasonable confidence, what ?V is. We 
have to be very confident that ?V won’t 
turn out to be zero or much lower than 
expected when the system is really 
needed. All of the imperfect devices on 
which we rely have that property; we are 


quite confident that they won’t fail 
catastrophically. My raincoat may leak 
in heavy rains, but it is not made of 
water soluble material that dissolves in 
the first real rain. My car may not get 
me to work on time, but I have reason¬ 
able confidence that it will not explode 
when I start it. Were that not the case, 

I would not use it. 

In fact, those who talk about specific 
leakage rates for SDI are guilty of gross 
oversimplification. The leakage rate is 
obviously going to depend on the struc¬ 
ture of the attack and the counter¬ 
measures used by the attacker. A single 
figure, without a clear statement of 
assumptions about the threat, is mean¬ 
ingless and misleading. Those who quote 
numbers such as “90 percent” have no 
basis for them. 

My papers did not conclude that there 
could be leaks. My assertion was that 
the system would not be trustworthy, 
that we would never have any confi¬ 
dence that the system would not fail. No 
SDI supporter has explained how we 
would establish confidence in such a 
system. Instead, supporters reply that it 
does not have to be leak-proof. 

In fact, all of our experience with 
easier software projects supports my per¬ 
sonal feeling that the likelihood of a 
catastrophic failure in an attack by a 
serious and sophisticated enemy is close 
to one. Mathematical theory confirms 
what we know from practical experi¬ 
ence. Small errors in software do not 
necessarily have small effects. There is 
no reason to believe that a small error 
will simply increase the “leakage rate.” 
Some big errors may not matter at all, 
but some small ones can be disastrous. 

Myers quotes Fred Brook’s excellent 
question, “How good is good enough?” 
I think that the answer is clear. To be 
good enough, we have to know, with 
high confidence, how good it is. To be 
good enough, we must know that the 
system will not fail catastrophically. 

Myers’s discussion of Safeguard ex¬ 
perience is misleading. He cites a low er¬ 
ror rate after deployment and ignores 
the fact that this system was, thank 
goodness, never used. It was subject to 
“demonstration tests” and used, briefly. 


in peacetime. This is analogous to 
throwing a glass of water at a raincoat 
and noting that most of it drips off. My 
sweater passes that test. Safeguard used 
nuclear tipped missiles, but the effect of 
nuclear explosions on the data process¬ 
ing capability was never tested. As 
Brooks pointed out in his essay, “Plan 
to Throw One Away,” the serious errors 
in software are discovered in real use, 
not in simulation or demonstration tests. 
His observation is especially relevant in 
situations where the characteristics of 
the problem are determined by a sophis¬ 
ticated enemy who is deliberately trying 
to cause such errors. Safeguard data 
does not tell us anything about the er¬ 
rors that show up when you first actual¬ 
ly use a system for “production.” 

In my view, the whole discussion of 
error rates is pseudoscience. Quantitative 
arguments always seem more profes¬ 
sional than qualitative ones, but they are 
only useful when the numbers are mean¬ 
ingful. In the case of error rates, a little 
thought will show that we don’t even 
know how to count errors. If I write a 
program on the assumption that an ar¬ 
ray has bounds [0:99] and testing shows 
that the bounds should have been 
[1:100], how many errors is that? There 
might be 88 places in the code that have 
to be changed. We might find those 
places, a few at a time in a sequence of 
35 tests. Do we count that as a single er¬ 
ror, 35 errors, or 88? Often errors in 
programs can be corrected in several dif¬ 
ferent ways. In the example, I could 
change the declaration, or change 88 
statements in the program. Is that one 
error or 88? When you look at real ex¬ 
amples, you find that the error counts 
are quite arbitrary; they depend on how 
the errors were discovered and how 
clever the programmer was when he 
made his corrections. 

Error statistics make excellent diver¬ 
sions but they do not matter. A low er¬ 
ror rate does not mean that the system 
will be effective. All that does matter is 
whether software works acceptably when 
first used by the customers; the sad 
answer is that, even in cases much 
simpler than SDI, it does not. What also 
matters is whether we can find all the 
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“serious” errors before we put software 
into use. The sad answer is that we can¬ 
not. What matters, too, is whether we 
could ever be confident that we had 
found the last serious error. Again, the 
sad answer is that we cannot. Software 
systems become trustworthy after real 
use, not before. They become trustwor¬ 
thy when the operating conditions are 
known and stable, not when they are 
unknown and subject to change by an 
opponent. 

The architectural issues raised by the 
SDI supporters and reported by Myers 
are also irrelevant diversions. Some 
claim that progress has been made by 
switching from a centralized architecture 
to a decentralized one. Examination of 
the original study, the Fletcher Report, 
shows that SDI designers always had 
planned a decentralized architecture. 
Some claim that a hierarchy modeled on 
a military command structure is an im¬ 
provement over the Fletcher design. Ex¬ 
amination of the Fletcher Report shows 
that they, quite wisely, rejected such a 


To the editor: 

I am pleased that Dave Parnas—the 
originator of the thought that SDI soft¬ 
ware will present serious problems—has 
seen fit to expand his argument as a 
response to my article. My article had a 
narrow focus: Will there be errors? 
Essentially all authorities agree that there 
will be errors, but there is one authority, 
namely the President, who has sold SDI 
to the public on the basis that it will 
render nuclear weapons “impotent and 
obsolete.” 

Some 60 to 70 percent of the people 
are said by polls to support this pro¬ 
gram. I think they expect perfect protec¬ 
tion. A dozen or so weapons getting 
through as a result of errors, destroying 
most of a dozen or so areas, would not 
be considered by the average citizen to 
be even adequate protection, let alone 


hierarchical scheme as having an Achilles 
heel, the computers at the root of such a 
hierarchy. 

All of the architectures that have been 
discussed propose a collection of sub¬ 
systems, each controlled by a large, and 
largely untestable, software package. 
Confidence in either the individual 
packages, or their successful coopera¬ 
tion, cannot be established. The mathe¬ 
matical properties that make software 
the biggest source of trouble in large 
systems are shared by all software sys¬ 
tems. Physical distribution is often 
useful but it does not simplify the devel¬ 
opment task. 

I am happy to see professional jour¬ 
nals such as Computer discussing the 
SDI software, but I hope future contri¬ 
butions will avoid the trap of discussing 
the non-issues introduced by politically 
motivated persons. 

David L. Parnas 

Queen’s University 

Kingston, Ontario 


perfect. The fact that all the technical 
authorities in the engineering and 
defense communities would be pleased 
with a system of such high capabilities 
would cut little ice with the average 
citizen. 

My article gathered up evidence from 
both those opposing SDI and those 
working on it and concluded that there 
will be errors. The fact of errors changes 
the nature of the debate on the political 
level over whether we should have such a 
system. Given the fact that there will be 
errors, it is then up to the citizens, the 
political community, strategic 
thinkers—whomever—to consider next 
steps. That is probably a discussion out¬ 
side the area of expertise of Computer. 

Ware Myers 

Claremont, Calif. 



Author: But the public has been “hooked” 
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CALL FOR PAPERS 

ACM-IEEE COMPUTER SOCIETY 
1987 FALL JOINT COMPUTER CONFERENCE 



EXPLORING THE KNOWLEDGE-BASED SOCIETY 


FJCC ’87 October 25-29,1987 INFOMART-DALLAS, TEXAS 


FJCC '87 is a professional conference targeted at aii professionais concerned with computing in research, deveiop- 
ment, and appiications. FJCC ’87 wiil provide a forum where corporate decision makers and other leaders in the field can 
meet to discuss the new and expected direction in the computer industry and profession, not only to announce new 
discoveries, but also to examine the impact and influence of these latest innovations. 


You are invited to submit: 

■ an original technical paper 

■ a survey paper 

■ a proposal for a panel/session discussion 

■ a proposal for a tutorial 

■ a proposal for a professional development seminar 

■ a proposal for a short workshop 

■ birds-of-a-feather session, poster presentation, etc. 

Papers should be complete and include an abstract. Papers 
will be refereed and accepted papers will be published in a 
proceedings available at the opening of the conference. 
Proposals should state the subject and purpose, and indicate 
expected participants. Papers, panels, and tutorials will be 
selected on the basis of technical quality, relevance of the 
subject matter, and value to the conference participants. 
Participants need not be members of the ASSOCIATION 
FOR COMPUTING MACHINERY or THE COMPUTER 
SOCIETY OF THE IEEE. 

DATES; 

March 15,1987 Papers and proposals due. 

Five copies of a paper or proposal are required. Send papers and 
panel session proposals to Dr. Stephen A. Szygenda. Send proposals 
for tutorials, workshops, and seminars to Toni Shetler. 

May 15,1987 Notification of acceptance sent. 

Authors will be sent special paper, instructions for preparing camera- 
ready copy, and a copyright release form which must be signed and 
returned with the camera-ready copy. 

July 1,1987 Camera-ready copy due. 


Conference topics will include, but not be 
limited to: 


Knowledge based systems 

• Expert systems 

• Architectures for A.I. 

• Natural languages 

• Machine learning 

• Speech/vision recognition 

• A.I. technology 

• Robotics 

• Hardware/software 

• Bio engineering & technology 
Computer aided engineering 

• Fault tolerant technologies 

• Algorithms 

• Applications areas 

Manufacturing systems 

• Factory automation 

• Paperless factory 

• Robotics 
Super computers 

• Parallel computation 

• High performance architects 

• Multiprocessors 

• Optical computing 


Workstations/personal computers 

• Technologies for engineering 
» Technologies for business 

• Technologies for publishing 
Communications networks 

• Local area networks 

• Protocols 

• Hardware/software 
Technologies around the world 

• Technology in Japan 

• Technology in Europe 

• Technology in Asia 
Related Issues 

• Small business development 

• Legal/financial concerns 

• Incubators 

• Technology transfer/ 
commercialization 


FOR EXHIBITORS 

FJCC ’87 considers EXHIBITS to be an important part of the total experience to be gained at the 1987 Fall 
Joint Computer Conference. Discriminating exhibitors will discover an excellentopportunity to display their 
products and interact with leaders of the computer industry and computer profession during the most 
exciting and innovative conference of the year. For details, contact: Cindy Cegelski or Kerry Kirschbraun, 
INFOMART 

1950 Stemmons Freeway. Dallas, Texas 75207 

(214) 746-3547 or (214) 746-3529 TELEX: 494 3073 INFO 


For further Information contact: 

Dr. Stephen A. Szygenda Ms. Toni Shetier 

Conference Chairman, FJCC '87 Professional Development Chair, FJCC '87 
The University of Texas TRW Systems Division W1/4454 

College of Engineering 7600 Colshire Dr, 

Cockrell Hall 2.510B McLean, VA. 22102 

Austin, TX, 78712-1080 

(512)471-1653 


Dr. Raymond Yeh 
Program Co-Chair, FJCC '87 
International Software Inc. 
12710 Research, Suite 301 
Austin, TX. 78759 
512-331-8866 


Dr. C. V. Ramamoorthy 
Program Co-Chair, FJCC '87 
Dept. EE and Computer Science 
University of California. Berkeley 
Berkeley. CA 94720 


THE COMPUTER SOCIETY 


Association for Computing Machinery 











TH Annual 

International Conference on 


March 30 - April 2, 1987 
Monterey, CA, USA 
Monterey Convention Center 


SOFTWARE ENGINEERING 

Formalizing and Automating the Software Process 


The th&muFormalizing and Automating the Software Process identifies the two essential activities for realizing the 
potential of Software Engineering. The first is to rigorously define software creation and evolution processes. The 
second is to create organizational and automated systems supporting these processes. This theme has guided the 
definition of a Technical Program organized into Process, Formalism and Automation Tracks, a Tutorial Program 
providing background information, and a Tools Fair in which a variety of available technology will be demonstrated. 

Each of the tracks in the Technical Program includes major talks, papers, workshop reports and panels that collectively 
expose and integrate relevant, current activities. The Process Track concerns approaches to defining, measuring, 
assessing, modifying and evolving software processes. Automated and organizational systems supporting these 
processes are the subject of the Automation Track. The Formalism Track covers both the use of formalism within the 
processes and the rigorous definition of the processes, their constituent activities and the supporting organizational and 
automated systems. 

The Tutorial Program precedes the other activities and provides in-depth, one-day introductions to a variety of technology 
pertinent to formalizing and automating the software process. The program covers database technology supporting 
software engineering, software development environments, knowledge-based programming environments, formal 
specification and verification techniques, and software reusability. 

The Tools Fair includes demonstrations of both production and prototype tools. It also includes in-depth, technical 
presentations covering particularly interesting and innovative tools. The Tools Fair parallels the Technical Program and 
its activities are scheduled to allow attendance at both activities. 


CHAIR 

WilUam E. Riddle 
Software Productivity Consortium 
PROGRAM CHAIRS 
Robert M. Balzer 

use Information Sciences Institute 
Kouichi Kishida 

Software Research Associates, Inc. 
TOOLS FAIR CHAIRS 
Larry E. Druffel 

Software Engineering Institute 
Jack C. Wileden 

University of Massachusetts 
TUTORIAL CHAIR 
Richard E. Fairley 
Wang Institute 

LOCAL ARRANGEMENTS CHAIR 
William M. Murray 
General Dyrtamics Corporation 


SPONSORED BY: 


The COMPUTER SOCIETY of the IEEE ^ 
Technical Committee on Software Engineering 


ACM Special Interest Group on Software Engineering 


Institute of Electrical and Electronics Engineers, Inc. 

Association for Computing Machinery 
Agence de I'lnformatique 
Association Francaise pour la Cyberaetique Economique et Technique 
The Fellowship of Engineering, United Kingdom 
Information Processing Association of Israel 
Israel Section of the IEEE 
Singapore Computer Society 
Singapore National Computer Board 
Software Engineers Association of Japan 
British Computer Society 







TOOLS FAIR 


31 March - 2 April 1987 


The Tools Fair runs parallel to the Technical Program, scheduled to allow attendance at both activities. The 
purpose of the Tools Fair is to provide conference attendees an opportunity to view a variety of production and 
prototype software development tools, toolsets and environments from both the research community and industry. 

Individual tools, integrated toolsets and full-scale environments will be demonstrated in an exhibition area, 
providing the opportunity to gain first-hand experience and informally discuss technical details. In addition, a 
sequence of special presentations will be devoted to the description and demonstration of the technical details of 
particularly interesting or innovative technology. 


Applications for space within the exhibition area and proposals for special presentations 
must be received by 30 January 1987. Presentation proposals will be judged on the 
depth of technical content, freedom from marketing "hype," and suitability for 
illustrating interesting and novel aspects. Applicants for space in the exhibition area 
are advised that marketing activity will not be allowed. 

To request exhibition space or propose a special presentation, 
contact either of the Tools Fair Chairs: 

Larry E. Druffel (412) 268 7740 
Jack C. Wileden (413) 545 0289 


TUTORIALS 


30 March 1987 


The Tutorial Program includes several in-depth, one-day introductions to a variety of technology pertinent to 
formalizing and automating the software process: 


Database Technology for Software Engineering John Nestor 

Software Engineering Institute 
Richard Snodgrass 
University of North Carolina, Chapel Hill 

Software Deveiopment Environments Peter B. Henderson 

State University of New York at Stony Brook 
Mark Ardis 
Wang Institute 

Format Specification and Verification RiShard A. Kemmerer 

University of California, Santa Barbara 

Knowledge-based Programming Environments David R. Barstow 

Schlumberger-Doll Research 


John B. Goodenough 
Software Engineering Institute 


Software Reusability 
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Guest Editors’ Introduction 


The Federal Aviation 
Administration’s 
Advanced Automation 
Program 


Valerio R. Hunt, US Department of Transportation, FAA 
Gregory V. Kloster, Knowlex Technology Corporation 


Engineering the 
world’s largest 
command and control 
system is a complex 
undertaking. This 
issue communicates 
the authors’ experi¬ 
ences in the design of 
the next-generation air 
traffic control system. 

14 


W e started working on this issue 
with the objective of capturing 
our collective experiences in 
adapting and innovating modern comput¬ 
er science and system engineering tech¬ 
niques and methods to the problem of air 
traffic control systems design. We recog¬ 
nize that the Advanced Automation Pro¬ 
gram is a complex technological under¬ 
taking that requires government and 
industry to address issues and problems in 
system safety, reliability, long system life, 
architecture design, software engineering, 
and man-machine interface, or MMI, de¬ 
sign in very new and innovative ways. We 
look at this special issue as a vehicle for 
technology transfer to readers that are 


concerned not only with the development 
of a safe air traffic control system, but 
with the technologies used in the design, 
development, and Implementation of 
large complex, highly available, and 
interactive systems. 

Computer automation was introduced 
into en-route and terminal radar air traffic 
control centers in the early to mid-1970’s. 
In the en-route centers flight data and 
radar data processing represent the key 
automation functions operating on IBM 
9020 computers. Automated radar data 
processing and limited flight data readout 
and input capabilities are operational in 
systems known as automated radar ter¬ 
minal systems, or ARTS, II and III. The 
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ARTS II system was implemented on Bur¬ 
roughs computers and the ARTS III/IIIA 
systems operate on Sperry Univac 
computers. 

The Advanced Automation Program 
consists of two major Federal Aviation 
Administration, or FAA, system acquisi¬ 
tions. The first is the host program, which 
involves the replacement of current IBM 
9020 computer systems at all en-route air 
traffic control centers. This acquisition 
was awarded (after a design competition) 
to IBM in July 1985. The second is the 
Advanced Automation System, or AAS, 
which replaces both the en-route and 
terminal approach control air traffic con¬ 
trol, or ATC, computer systems over the 
next decade. The AAS will provide the 
computers, software, and controller work¬ 
stations (called sector suites) for integrated 
en-route and terminal radar ATC. The 
AAS will also include a tower control com¬ 
puter complex for use by the controllers in 
the tower cabs. This new system will 
replace the en-route and terminal ATC 
computers, flight strip printers and display 
equipment, and the backup radar display 
system. 

The AAS program consists of a two- 
phased government acquisition where the 
first phase includes a competitive design 
and prototype “fly-off” between two in¬ 
dustrial teams lead by GM-Hughes Air¬ 
craft and IBM. The second phase consists 
of a winner-take-all production and im¬ 
plementation contract. (Because of the 
nature of the design competition we have 
taken great pains to avoid publication of 
technical data that might compromise the 
competition and proprietary rights of the 
competitors.) All of the articles in this 
special issue, with the exception of one, 
deal with the AAS program. 

The FAA has accumulated a legacy of 
experiences in both ATC operations and 
software maintenance and test. The con¬ 
sensus has been that the new advanced 
ATC automation system must 

• provide a time-responsive set of ATC 
services (to the controller) that are highly 
available and feature inherent protection 
mechanisms to detect, contain, and 
recover from faults; 

• provide for evolution in ATC func¬ 
tions and capabilities without affecting 
safety and required redesign of the basic 
system; and 

• provide a user/computer interface 
that facilitates the evolution of the system 
and accommodates the basic manner in 
which the controller performs his or her 
ATC information processing tasks today. 


Based on our past experiences and this 
consensus, we feel that risks that might 
result in either unsafe, unsuitable opera¬ 
tions or costly high-risk technology are 
both real and must be eliminated or greatly 
reduced. We recognize that the AAS poses 
several challenges to the engineer and 
designer. 

Since the inception of the AAS re¬ 
quirements definition effort over the past 
six years, significant progress has been 
made in MMI (also termed computer- 
human interface) design and human engi¬ 
neering methods: computer workstation 
display technology: software engineering 
practices; tools; computer system perfor¬ 
mance modeling; and computer system 
fault tolerance. We have felt strongly that 
these practices, tools, and methods must 
be used in order to mitigate the critical 
technical risks associated with either a sys¬ 
tem design that inhibits system evolution 
or a user interface that is not acceptable to 
air traffic controllers. 

Of paramount concern is the develop¬ 
ment of a safe system architecture that 
provides adequate coverage and protec¬ 
tion from faults. In response to this latter 
concern the FAA has not only levied on the 
AAS stringent reliability and availability 
requirements, but has adopted standards 
and practices' aimed at the development 
of a highly reliable system. 

The strategy selected by FAA to meet 
these unique requirements resulted in ex¬ 
tensive focus on precontract requirements 
definition activities (prior to the design 
competition phase award) and prime con¬ 
tractor system design in the early part of 
the program. The articles in this issue ad¬ 
dress many of those activities undertaken 
prior to the start of the AAS Design Com¬ 
petition Phase in August 1984. Postcon¬ 
tract award activities have been described 
in the AAS Statement of Work. ^ Some of 
these efforts represent further refinement 
and implementation of FAA initiatives in 
MMI requirements engineering and con¬ 
troller workstation design. Others require 
the prime contractors to refine and devel¬ 
op innovative approaches to engineering a 
fault-tolerant computer architecture and 
distributed software processes. 

Background and 
overview of the AAS 
program 

The first article in this issue examines 
the challenges and hurdles faced by 


government engineers and industry devel¬ 
opers. In this article. TheFAA’s Advanced 
Automation System: Strategies for Future 
Air Traffic Control Systems, Valerio 
Hunt and Andres Zellweger describe the 
system acquisition and transition strat¬ 
egies for the FAA’s Advanced Auto¬ 
mation Program. The article also provides 
a background discussion (in vignette 
form) of the US air traffic control system 
to familiarize the reader with this applica¬ 
tion. In particular, the authors examine 
the technological demands that the AAS 
requirements place on the system designer. 

The investment in time and money 
(estimated $2-3 billion) to design and im¬ 
plement such a system dictates balancing 
the factors of safety, reliability, and long 
system life. The current ATC automation 
systems will have been in service over 20 
years when they are replaced by the Ad¬ 
vanced Automation System, and there is 
no reason to suspect that the basic AAS 
system design and software will not have a 
20-to 30-year life span. 

Such factors place difficult demands on 
the system designer. The functions to be 
performed by the computer system (and, 
therefore, the man-machine interface), the 
external data sources (aircraft surveillance 
systems, weather sensors, navigation sys¬ 
tems, etc.), as well as the traffic levels, air 
fleet mix, aircraft performance charac¬ 
teristics, and avionic capabilities all 
change over time. The AAS designers 
must ensure that this evolution can be ac¬ 
commodated at a reasonable cost and 
without detrimental impact on system 
reliability (hardware and software) and on 
the critical man-machine interface design. 

A second demand on the system de¬ 
signer that stems from the long system life 
expectancy is the need to accommodate, 
without significant system perturbation, 
upgrades of hardware technology. This re¬ 
quirement stems from the fact that today’s 
computer generation for large commercial 
systems are 4-7 years and even less in the 
rapidly expanding microprocessor area. 
Government and industry experience in 
the last decade has shown that cost- 
effective computing, from a total life cycle 
cost viewpoint, is best achieved by a well- 
defined capacity management program 
that permits upgrades as demand increases 
or as a hardware generation is superseded. 
Without an AAS design that permits hard¬ 
ware upgrades, the initial computer hard¬ 
ware installed only have to be sized to 
handle the largest projected demand for 
traffic and functional growth throughout 
the system life. Maintenance cost would be 
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unacceptably high by the end of the sys¬ 
tem’s life since it would represent a 20- to 
30-year-old technology. 

Following the above strategy and apply¬ 
ing computer science and software engi¬ 
neering principles of the 1980’s will help 
achieve the extensibility characteristics 
necessary for a successful long system life, 
but this is not enough. If a system with the 
stringent performance and reliability char¬ 
acteristics of the ATC system is to evolve in 
a cost-effective manner, the system 
designer must be able to anticipate the 
most likely course of evolution and the 
nature of the changes that can be ex¬ 
pected. For example, the input/output 
structure should anticipate future system 
interfaces and the data structures should 
anticipate data attributes that might 
become important as more of the ATC 
decision-making responsibility is shifted 
to the computer. The problem for the sys¬ 
tem designer arises from the fact that no 
firm requirements for the system inter¬ 
faces of functions anticipated for the 
1990’s and beyond exist at this time. 

To help add the proper evolutionary 
characteristics to the system design, FAA 
has developed a functional and perfor¬ 
mance description of what, to the best of 
our current knowledge, a highly auto¬ 
mated ATC system would be.^ This 
description places particular emphasis on 
how the advanced functions might inter¬ 
face with the ATC computer system that 
will actually be built by the AAS contrac¬ 
tors and that will form the starting point 
for future evolution. The AAS system 
designers are required by contract to show 
FAA, at various stages of system design 
and development, how their particular 
design can be extended to accommodate 
these likely future functions. 


Air traffic control 
system architecture 

In the second article. Evaluating Pro¬ 
posed Architectures for the FAA’s Ad¬ 
vanced Automation System, Jean-Marc 
Garot, Thomas Hawker, and Delbert 
Weathers examine the fundamental 
methods used by the FAA to evaluate 
complex distributed system architectures. 
This article examines the complex issues 
involved in architecture design, cites 
lessons learned from other programs, and 
describes the approach used to evaluate 
system architectures. This process should 
prove useful to those interested in both the 


development and design validation of 
complex systems. Because of the nature of 
the AAS design competition, this article 
has avoided mentioning specifics concern¬ 
ing each prime contractor’s architecture. 
What is noteworthy is that the application 
of a formal evaluation process is essential 
to determining that the system design (as 
proposed) satisfies AAS requirements. 

Clearly the basic system design, in terms 
of both hardware and software structure, 
will have to remain intact for the total sys¬ 
tem life. So an important evaluation 
method must qualitatively examine how 
the system is expected to be augmented 
and modified as the system evolves. To 
make this possible, FAA has required that 
the system be designed around a local 
communications network (with the requi¬ 
site reliability characteristics) based on 
local area network technology and indus¬ 
try-accepted protocol standards. This will 
allow the introduction of new hardware 
technology without major system pertur¬ 
bations. To complement the hardware 
strategy, software will be functionally dis¬ 
tributed and, perhaps more importantly, 
developed in a single high-order language 
(such as Ada) that permits easy migration 
from one processor to another. An impor¬ 
tant criterion in the evaluation of pro¬ 
posed architectures will be the impact of 
change on system stability since the ATC 
application cannot tolerate degradation in 
system reliability and availability during 
and after a change. 


Controller MMI and 
operational suitability 

An operative phrase used in connection 
with the AAS is “operational suitability.” 
While the value of accurately capturing 
user knowledge and infusing this knowl¬ 
edge into the AAS system development 
process is clear enough, the process of 
doing this can be quite a bit more complex 
than it may seem. Users may be biased by 
their own limited experience with particu¬ 
lar design features, peculiarities of their 
operations at a given air traffic sector, or 
the interaction techniques they employ 
when using the system. Users also tend to 
offer isolated “fixes” to perceived prob¬ 
lems, rather than to regard functions in the 
context of system design decisions that 
respond to functional and performance 
requirements. Lastly, user terminology 
often differs from engineering terminol¬ 
ogy. This results in fertile ground for 
misinterpretation of requirements on both 


ends. It is for these and other reasons that 
others have previously noted that noncriti- 
cal acceptance of user inputs may consti¬ 
tute the first step in the design process that 
will most assuredly result in an operation¬ 
ally unsuitable design. 

The FAA’s Advanced Automation Pro¬ 
gram Office and Air Traffic Service have 
successfully implemented a program of 
close cooperation and involvement by 
“users” in the full cycle of AAS engi¬ 
neering and development. There has been 
a certain amount of concern that the AAS 
end-product (in terms of the MMI soft¬ 
ware and controller workstation) might 
not be acceptable to the air traffic con¬ 
troller. Also, there was the concern, given 
the complexity of the controller’s job, that 
there was significant risk in misinterpret¬ 
ing and developing incomplete require¬ 
ments. The difficulty lies in attempting to 
develop a system with a new man-machine 
interface that is expected to be available in 
the early 1990’s. This risk has been miti¬ 
gated with the formation in 1983 of the 
FAA’s sector suite requirements valida¬ 
tion team, or SSRVT, and the subsequent 
application of comprehensive MMI design 
and human factors methods. So impor¬ 
tant is this undertaking two articles in this 
issue address it. 

In the third article. Engineering the 
Man-Machine Interface for Air Traffic 
Control, Gregory Kloster and Andres 
Zellweger not only examine the process 
used to formulate MMI requirements, but 
describe the life cycle involvement of the 
SSRVT in that process. Of note are discus¬ 
sion and examples that show how this 
method was used to formulate an opera¬ 
tions concept for the AAS man-machine 
interface, derive MMI functional re¬ 
quirements for the controller interface 
language, and determine requirements for 
the controller workstation. The origins of 
this method were developed at the TRW 
Defense Systems Group and refined at 
Computer Technology Associates, Inc.'^ 
This we feel represents a dramatic depar¬ 
ture from the way systems are typically ac¬ 
quired by the government. The article also 
describes prime contractor activities after 
the design competition phase contract 
award in August 1984. 

In the fourth article. The Quantification 
of Operational Suitability, Mark Phillips 
describes how the SSRVT and the FAA 
both derive user requirements and assess 
the operational suitability of the emerging 
MMI designs during the design competi¬ 
tion phase. This process does not merely 
consider the users to be passive partici- 
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pants or make attempts at identifying re¬ 
quirements that are “likely” to result in a 
“user friendly” design, but shares infor¬ 
mation on how a team of users and human 
factors specialists made a joint commit¬ 
ment to ensure the significant and sus¬ 
tained involvement of a representative 
group of actively working air traffic con¬ 
trollers. Again, one cannot underestimate 
the importance of applying evaluation 
methods that offer both quantitative and 
qualitative evaluations of ergonomic 
quality. It is here that we offer a compre¬ 
hensive look at how complex MMI designs 
can be evaluated in terms of operational 
suitability and ergonomic quality metrics. 

FAA computer capacity 
management 

In the fifth article. Capacity Manage¬ 
ment of Air Traffic Control Computer 
Systems, Sandra Bleistein, Robert 
Goettge, Frank Petroski, and Robert 
Wiseman describe how performance 
modeling and analysis is integral to the 
FAA’s strategy of computer capacity 
management for the current 9020 en-route 
computer system, host computer system, 
and the future A AS. Capacity manage¬ 
ment of these three generations of 
computer systems consists of five common 
elements: 

(1) specification of performance re¬ 
quirements in terms of computer re¬ 
sponsiveness; 

(2) projection of air traffic workloads; 

(3) development of performance and 
workload measurement capabili¬ 
ties; 

(4) modeling and prediction of perfor¬ 
mance; and 

(5) development of a program and re¬ 
lated procedures for capacity man¬ 
agement. 

Each of these elements is discussed in the 
article. The evolution from basic capabili¬ 
ties in the 9020 system to the anticipated 
AAS capabilities is described. Results 
from each system and their influence on 
the capabilities of the succeeding system 
are presented. 

AAS dependability 

In the last article. On the Achievement 
of a Highly Dependable and Fault- 
Tolerant Air Traffic Control System, A1 
Avizienis and Dan Ball describe the evolu¬ 
tion of the AAS reliability, maintainabil¬ 


ity, and availability (RMA) requirements 
and discuss issues and concerns in achiev¬ 
ing a highly reliable AAS. The authors 
contrast the reliability problems of the 
existing system and goals for the new 
AAS. Of particular interest is a discussion 
on the evolution of the AAS RMA re¬ 
quirements and the FAA’s strategy for 
achieving a highly reliable AAS. The arti¬ 
cle concludes with lessons learned so far 
and guidelines for future acquisitions of 
complex fault-tolerant systems. 


T he significance and scope of the 
FAA’s modernization programs 
for air traffic control should not be 
underestimated. The technology fallout of 
the Advanced Automation Program has 
implications for government, industrial, 
and commercial organizations engaged in 
real-time systems, distributed computing, 
design of fault-tolerant software, design 
of complex interactive user interfaces, 
testing, capacity management, and use of 
new software development tools and Ada. 
Innovative tools, techniques, and methods 
will continue to be developed by the FAA, 
its support contractors, and prime con¬ 
tractors as the AAS moves into the acqui¬ 
sition phase of full-scale development, 
production, and test. Our view is that 
additional technical contributions will be 
forthcoming in this magazine and other 
IEEE publications. It is in the spirit of pro¬ 
moting technology transfer and communi¬ 
cating our collective experiences that we 
hope to improve the management and de¬ 
velopment of complex ultra-reliable 
systems. □ 
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The FAA’s new- 
technology air traffic 
control computer 
system will lead to 
highly automated air 
traffic control by the 
turn of the century. 


A ir transport has become the domi¬ 
nant mode of intercity common- 
carrier passanger travel in the 
United States. This has come about in 
large part as a result of continual applica¬ 
tion of technological advances. These ad¬ 
vances have also improved service, low¬ 
ered prices, and ensured greater safety. As 
defined in federal aviation regulations, air 
traffic control, or ATC, is a service 
operated by the Federal Aviation Admin¬ 
istration, or FAA, to promote the safe, 
orderly, and expeditious flow of air traf¬ 
fic. This service involves a myriad of inter¬ 
related elements that have been combined 
in an evolutionary process, over the years, 
to form the ATC system. This system uses 
a complex of ground equipment, airborne 
equipment, personnel, communications, 
navigational aids, displays, radar, com¬ 
puters, facilities, and airways. Figure 1 
provides an overview of how these ele¬ 
ments interact to form an ATC system. In 
the foreseeable future, significant in¬ 


creases in the volume of air traffic activity 
are indicated for both domestic and inter¬ 
national air routes. Deregulation has 
already led to a significant increase in com¬ 
muter and air taxi activity. The greatest 
traffic growth is projected in general avia¬ 
tion with a fleet mix from small single¬ 
engine aircraft with only a radio and 
perhaps a transponder to business jets 
with avionics that approach the sophisti¬ 
cation of commercial carrier avionics. 

To understand where we are today and 
where ATC may go in the future, a brief 
review of ATC history is helpful. The 
rapid growth of aviation in the 1950’s dic¬ 
tated an urgent need to expand the capaci¬ 
ty of the ATC system. This era saw the 
first tentative application of automation 
to ATC. From this start in the 1950’s, ap¬ 
plication of automation in ATC has grown 
enormously. 

The planning, design, and development 
activities of the 1950’s and 1960’s culmi¬ 
nated in the introduction, around 1970, of 
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Figure 1. Elements of the future air traffic control system. 


sophisticated computer systems to assist 
the air traffic controller. The National 
Airspace System, or NAS, Stage A sys¬ 
tem, consisting of IBM 360 model 50’s and 
65’s modified to operate in a fault-tolerant 
multiprocessor configuration (designated 
the IBM 9020), was installed at the 20 en- 
route traffie control centers. A fault- 
tolerant display channel distributes data to 
40-60 controller suites and refreshes the 
high-resolution plan view display, or 
PVD, in each controller suite. In addition, 
there is an independent backup system 
called the direct access radar channel, or 
DARC, that can provide processed radar 
data to the PVD in case of a failure of the 
IBM 9020 (see Figure 2). It is interesting to 
note that controllers have the abihty to 


switch to DARC individually because each 
controller is the best judge of when the 
9020 has deteriorated to the point where it 
is no longer suitable for the controller’s 
needs. Figure 3 provides an overview of 
the en-route system and its links to the rest 
of the ATC system. 

Air-traffic terminal-approach control 
facilities provide ATC services for the 
geographic airspace surrounding airports. 
These terminal facilities coordinate ATC 
operations with both air traffic towers and 
en-route centers. Sbrty-three of the larger 
terminal facilities are equipped with 
ARTS III computers from Univac. These 
were initially operated as single-CPU 
systems but have been expanded, using the 
same Univac technology, to fault-tolerant 


multiprocessors. An ARTS II minicom¬ 
puter-based ATC system for processing 
and display of surveillanee data at smaller 
airports was developed in the 1970’s and 
deployed at over 80 airports. 

As part of its National Aviation System 
Plan, the FAA has initiated the design of 
the Advanced Automation System, or 
AAS, to replace both the en-route and ter¬ 
minal ATC computer systems over the 
next decade. The AAS will provide the 
computer hardware and software and con¬ 
troller workstations (called sector suites) 
for integrated en-route and terminal radar 
ATC. The system will also include a tower 
control computer complex (computer 
hardware, software, and consoles)—for 
use by the controllers in the tower cabs— 
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Figure 2. Today’s ATC system. 


that will be supported remotely from 23 
central facilities. The AAS will replace the 
en-route and terminal ATC computers, 
flight strips and display equipment, and 
the radar display backup system (DARC). 

This article will characterize the nature 
of ATC automation and of the AAS, pre¬ 
sent the major objectives to be achieved by 
the AAS system design, and discuss in 
detail the major challenges faced by 
government and industry in the design, 
development, and implementation of such 
a system. These challenges, not necessarily 
in order of difficulty or importance, are 


(2) accommodating, over a 20- to 
30-year system life, changes in the external 
environment (e.g., improvements in air¬ 
craft avionics and weather and surveil¬ 
lance data information sources or charac¬ 
teristics or both), in the way controllers do 
their job, and in computer technology, all 
in a cost-effective manner; 

(3) supporting, for 24 hours a day, seven 
days a week, operation with no service in¬ 
terruptions and with a robustness that per¬ 
mits continued safe system operation in the 
light of both hardware and software fail¬ 
ures. A related challenge is that the system 
must provide correct outputs to the con¬ 
troller, particularly as, over the next two 
decades, more and more of the cognitive 
aspects of air traffic control migrate from 


(1) transitioning to a new system with¬ 
out compromising safety, interrupting ser¬ 
vice, and negatively impacting on the con¬ 
troller and maintenance work force; 


the controller to the ATC computer; 

(4) ensuring that the man-machine in¬ 
terface allows the automation system to be 
used as an effective partner by the air traf¬ 
fic controller and that, as the system 
changes over time, the delicate relation¬ 
ship between the controller and the com¬ 
puter does not become unbalanced to the 
point of compromising safety or affecting 
ATC efficiency; and 

(5) finding an acquisition strategy that 
will allow the government, in partnership 
with industry, to achieve the best possible 
design and, at the same time, will lead to 
early system implementation at an accept¬ 
able price. 

The five sections that address these 
challenges were written for the reader with 
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Figure 3. En-route automation system interaction with the ATC system. 


a basic understanding of the overall air 
traffic control process and the specific role 
of the air traffic controller. The reader is 
encouraged to read the three sidebars ac¬ 
companying this article to obtain the 
necessary ATC background. 

Transition strategy 

Background. Transition from the ex¬ 
isting ATC automation system to a new 
system, the AAS, is perhaps the most dif¬ 
ficult aspect of the entire AAS program. 
The furor created in 1985 when the Inter¬ 
nal Revenue Service was not able to pro¬ 
cess our income tax returns in a timely 
manner cannot compare with the chaos 
that would be created if air traffic were to 


be curtailed for an entire en-route center 
for even a few hours. 

The problem of transition to the AAS 
has several interrelated dimensions. 
Because ATC must continue 24 hours a 
day, seven days a week, no aspect of the 
transition process can interrupt service. 
Safety of air traffic, through the transition 
period and after a new system is installed, 
cannot be compromised. These two re¬ 
quirements clearly call for very careful 
planning, extensive testing, and a fallback 
scheme to a proven and stable system until 
the newly introduced system has suc¬ 
cessfully overcome its growing pains. 
Steps taken to ensure continuity of service 
and system safety will be addressed later in 
this section. 

Another aspect of transition that must 


How air traffic control 
works 

The principal function of the FAA’s 
ATC system is to provide for the safe 
and efficient movement of aircraft, en¬ 
suring that adequate separation stan¬ 
dards are maintained at all times. The j 

airspace is divided generally into four 
separate areas; terminal control, or 
the airspace surrounding the airports; 
the en-route control, or the airspace 
between the airports; and the en-route 
control offshore, or the space con¬ 
tiguous to the oceans for arriving and 
departing traffic; and, finally, the 
space over the oceanic areas proper. 

This ATC system is an extremely 

large system, consisting of a number 

of different components. First of ail, 

and most important probably, are the 

pilots. There are some 800,000 to 

900,000 pilots licensed in the US 

system, divided among military, air- ! 

lines, and general aviation. There are 

some 15,000 airports in the United 

States and some 400,000 miles of air- j 

ways. Traffic is controlled through a i 

set of formal procedures and rules. ; 

The basic ATC system is very sim¬ 
ple. It begins with the pilot requesting 
approval of a detailed flight plan from 
the air traffic controller. Permission to 
actually fly this path, called “clear¬ 
ance,” is issued by the controller. As 
the aircraft travels along this approved 
flight path, there is independent 
surveillance provided through ground- 
based radars and transponders on 
board the aircraft. This surveillance 
system includes a unique aircraft 
identification as well as the position 
of each aircraft. This information is 
relayed to the air traffic controller 
located in the control center. The con¬ 
troller monitors progress of the air¬ 
craft along the approved flight plan. 

There is a ground-to-air network for 


be carefully managed is the introduction 
of the system to the work force—the 
thousands of controllers and hardware or 
software maintenance people affected by 
the new system. The FAA work force is 
highly trained and very stable (i.e., most 
controllers and maintenance technicians 
stay with the FAA for thier entire career). 
Where an airline can hire a new flight at¬ 
tendant and, within a few short weeks of 
training, replace the attendant in case of a 
strike, the FAA must invest several years 
of training to get a fully qualified air traf- 
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communications between the air traf¬ 
fic controiiers and the piiots that pro¬ 
vides the means of delivering clear¬ 
ances to the pilot and receiving 
position reports from the pilot along 
the flight path. Clearances are deliv¬ 
ered and position reports provided on 
this path. 

For purposes of ATC Jurisdiction, 
the lower 48 states in the United 
States are divided into 20 major 
regions, each of which has an en- 
route control center. The airspace in 
each region is further subdivided into 
sectors, with a total number of sec¬ 
tors in the United States on the order 
of 650. This allocates some 30-odd 
sectors to each center on the average. 
A team of one to three air traffic con¬ 
trollers is responsible for the separa¬ 
tion of aircraft within a sector and for 
managing the efficient flow of traffic 
through the sector. 

Air traffic sen/ices are provided on 
a first-come, first-served basis, and 
the first priority for air traffic con¬ 
trollers is to provide safe aircraft 
separation and all safety advisories. 
Air traffic controllers are obligated to 
use their own best judgment in con¬ 
sidering various sources of data and 
using information received through 
automation services in preference to 
information received through non¬ 
automation channels. Radar separa¬ 
tion should be used if it is available, 
or nonradar separation if radar is not 
available. There are a number of areas 
in the lower 48 states where radar 
data is simply not available. There are 
also a number of special kinds of 
“traffic” that the air traffic controller 
also “works,” i.e., handling air am¬ 
bulances and evacuation procedures 
or expediting special flights for the 
President or for military personnel. 
When an aircraft passes from one 
controller’s jurisdiction to that of 
another controller, there is a formal 


hand-off procedure. The controller is 
also obligated to accept and act on air 
crew requests if possible and to pro¬ 
vide traffic and environmental ad¬ 
visories, weather, and other environ¬ 
mental information. 

Today the controller’s principal 
source of information is a 19-inch 
diameter CRT, called a plan view 
display or PVD, which is a mono¬ 
chrome stroke writer. This PVD pro¬ 
vides several kinds of information: 
first, the actual ground track of each 
aircraft is displayed; second, the local 
navigation aid (navaid) locations are 
shown; and third, weather and other 
environmental data is presented. 

Also, all of the airways passing 
through the sector are displayed as 
lines. A second source of data is in¬ 
formation regarding the pilot’s in¬ 
tended flight path and progress along 
that path. This information is printed 
periodically on “flight progress 
strips.” These are placed in plastic 


holders to permit the controller to ar¬ 
range strips in an appropriate order 
on a board next to the PVD and to 
manually mark the strips, primarily 
with the information regarding “clear¬ 
ances” (i.e., commands) given to the 
pilots, and the most recent flight 
progress. There are radio messages 
to and from the pilot, and to and from 
the other controllers who will later 
assume control responsibility for the 
aircraft, as it moves to the next sec¬ 
tor. The environmental information in¬ 
cludes weather and the status of the 
facilities, both at the departure and ar¬ 
rival airports. A great deal of coordina¬ 
tion is required between air traffic 
controllers at different points along 
the path of flight. Instructions and 
clearances have to be provided to the 
pilot. There are data inputs by the air 
traffic controller to the ATC computer 
system through the use of a keyboard 
and/or a track ball. 



tion. On the left is the 19-inch PVD with a number of controis and in¬ 
put/output devices. On the right are bays used for hoiding the paper 
fiight progress strips; and as these are updated by the controiier, they 
must be positioned manuaiiy in the bays for the most convenient infor¬ 
mation dispiay to the controiier. 


fic controller. The FAA has taken years to 
recover from the controller strike of 1981. 
To ensure that the transition to the AAS 
accommodates the work force, the AAS 
program has been structured to involve the 
user throughout—beginning with require¬ 
ment definition and continuing through 
system design, development, test, and im¬ 
plementation. This user involvement and 
an extensive training program, formulated 
in parallel with system design, are expected 
to contribute to user acceptance of the new 
system. More detail on some of the steps 


taken to keep the user involved are dis¬ 
cussed in the section of the man-machine 
interface. 

Successful transition in the ATC en¬ 
vironment requires that there be a high 
degree of convergence in terms of func¬ 
tionality and performance between an ex¬ 
isting system and a new one replacing it. If 
one is to achieve user acceptance and 
maintain system safety, convergence 
means that a particular function in the old 
and new systems should not exhibit vastly 
different characteristics to the controller. 


If the same function does not work the 
same way, the potential for human error is 
high because ATC is based on rapid con¬ 
troller analysis of data and subsequent 
decision making. Controllers depend on 
familiar display cues to carry out their job 
effectively and safely. This presents a 
dilemma to the designer, who always finds 
improved ways of implementing a func¬ 
tion and of building the man-machine in¬ 
terface. 

Another transition constraint in ATC is 
that a new system, when introduced, must 
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have at least the level of functionality of 
the old system because, once again, safety 
is compromised if one does not provide 
controllers with functions on which they 
have become dependent. As a result, it is 
not possible to follow the strategy of 
developing and implementing a basic or 
core system and adding complexity gradu¬ 
ally, a technique that has been successfully 
used to reduce the development risk in 
many other large systems. 

The need for service continuity and sys¬ 
tem safety have some far-reaching impacts 
on system requirements and on the overall 
program strategy. Foremost among these 
are the need for an incremental replace¬ 
ment approach, an extensive and realistic 
test program, and a cut-over strategy that 
provides for rapid switch-over (less than 
one minute) from the old to the new sys¬ 
tem and from the new system back to the 
old. 

Transition steps. At first glance it would 
appear that developing an entire system in 
a single step and limiting the transition to a 
single “disruption” might be the preferred 
approach to transition of a large system 
like the A AS. Experience with other large 
systems has shown that, in reality, most 
programs that have not divided develop¬ 
ment and implementation into a number 
of manageable steps have failed. A multi- 
step approach that also limits the degree of 
change at any one time is, therefore, ex¬ 
pected to facilitate transition from the 
user’s viewpoint. 

Usually the incremental replacement 
approach is achieved by replacing a few 
functions of a system at one time. Unfor¬ 
tunately, the complex, “worn out” soft¬ 
ware in the FAA’s existing 9020 system has 
been compared to a mess of intertwined 
spaghetti and, therefore, doesn’t lend 
itself to this approach. The strategy 
adopted by the FAA calls for 

• Initial replacement of the aging 9020 
central computer complex with a current- 
generation, instruction-compatible com¬ 
puter (duplex IBM 3083’s, called the host 
computer). The application software is be¬ 
ing “rehosted” with changes only to the 
monitor. This step provides system capaci¬ 
ty to alleviate a CPU shortage in the 9020’s 
and will become a stable transition vehicle 
for the rest of the transition to the ultimate 
AAS. 

• Next, the controller workstations will 
be replaced with new workstations called 
sector suites. A local area network will be 
added to connect the host to the sector 


suites. While significant local processing 
will be available in the sector suites, the 
bulk of the ATC processing, namely the 
radar data processing, or RDP, and flight 
data processing, or FDP, will still be done 
by today’s software in the host. This step is 
expected to require on the order of 100,000 
source lines of software changes to the 
host and about the same amount of new 
software for the sector suites. The in¬ 
troduction of sector suites will have a 
significant impact on the controller since it 
implements the new man-machine inter¬ 
face, including the electronic display and 
manipulation of flight progress strips. 
This stage is called the initial sector suite 
system or ISSS. 

• The third step in the transition will be 
the replacement of the bulk of the ATC 
application software. The host is also like¬ 
ly to be replaced because, by this time, it 
will represent technology that is over seven 
years old and because the AAS prime con¬ 
tractor may choose a different family of 
computers to meet the central processing 
needs of the system. This system is called 
the area control computer complex or 
ACCC. The FAA is currently exploring 
the proper staging of the terminal and en- 
route elements of the ACCC. 

• The ACCC, when first installed, will 
be used strictly for terminal or for en-route 
air traffic control and will have only a 
limited number of new functions. It is 
planned, over the first five years of the 
ACCC operation, to begin the transition 
to the higher levels of ATC automation 
described in the sidebar entitled “Air 
Traffic Control Today and Tomorrow” 
and also to gradually integrate the en- 
route system with the approach and depar¬ 
ture radar control functions. This will 
complete the replacement of the 1970’s 
vintage computer equipment at some 200 
busier airports. 

Test program. When a new system is in¬ 
troduced at each step of this transition, it 
must exhibit a high level of stability- 
meantime between failure must be at least 
as high as that of the system being re¬ 
placed. This demands a design and devel¬ 
opment process aimed at system correct¬ 
ness and minimization of latent errors, 
particularly in the software. A thorough 
test program is essential. The FAA will 
create a realistic test environment at its 
technical center in Atlantic City, New 
Jersey, to permit extensive tests of system 
functionality, system performance under 
normal and stress conditions, system relia¬ 
bility and recovery capability under a 


variety of fault conditions, and system in¬ 
tegration into the overall ATC environ¬ 
ment. The new automation system will be 
subjected to a comprehensive operational 
test and evaluation program to find any 
potential problems in the controller inter¬ 
face or in system maintainability. For the 
host testing (conducted in 1986) this was 
achieved by installing a separate host 
system at the technical center and running 
simulations of the system operation for a 
number of specific field sites with exten¬ 
sive participation of controllers and main¬ 
tenance staffs from each of these sites. In¬ 
stallation and cut-over procedures are 
repeated a number of times at the technical 
center to minimize the risk of an ATC sys¬ 
tem outage during this critical process at 
the en-route centers. Finally, when a sys¬ 
tem is installed at the field site, another 
period of testing is required to uncover 
and fix any possible site-specific problem. 

Experience has shown that even with the 
degree of testing outlined above, problems 
remain in the system that are not un¬ 
covered until operational use begins. For 
that reason, initial operational use is 
limited to low-activity periods. During 
traditional morning and evening peaks, 
the old system remains in operation. To 
provide additional protection during the 
first weeks of full-time operation with the 
new system, the old system is kept at the 
facility as a backup. 

Transition summary. While this cau¬ 
tious strategy for bringing in a system is 
necessary for reasons of safety, it carries 
with it a number of implications for the 
computer system: 

• Because so much dependence for 
ATC safety is placed on the backup capa¬ 
bility of the old system, only minimal 
changes to the old system are permitted so 
that its stability is not compromised. This 
can be a serious constraint when the new 
system contains, as an integral part, por¬ 
tions of the old system. 

• Rapid switch-over between an old and 
a new system requires at least a switch to 
connect the systems and possibly shared 
peripherals. Figure 4 shows the 9020/host 
transition configuration. Physical installa¬ 
tion therefore may require shutdown of 
portions of the old system for some 
period. In the case of host installation, a 
24-hour 9020 shutdown is required. Since 
no site can tolerate a 24-hour period when 
only the radar backup system (DARC) is 
available to the controllers, the host in¬ 
stallation had to be broken into several 
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shorter periods to coincide with low activi¬ 
ty at the center. 

• A final implication is that when the 
new sector suites are introduced, each 
center must have two control rooms. 
While this may appear to represent an un¬ 
necessary cost, it turns out that having a 
room with all of the new sector suites in it 
is required to provide a realistic controller 
training lab for the new equipment. 

In conclusion, it is evident that proper 
transition to a new ATC system has far- 
reaching implications—additional re¬ 
quirements, special design considerations, 
a comprehensive test program that re¬ 
quires sophisticated simulators, and, 
perhaps most important, a need for care¬ 
ful planning and preparation for a com¬ 
plex process that involves the coordinated 
efforts of several thousand people. 

The man-machine 
interface 

Perhaps the most neglected aspect in the 
development of large computer systems 
has been the interface between the com¬ 
puter and the user. The arguments that 


users don’t know how to state their re¬ 
quirements and should not “look over the 
programmer’s shoulder” have consider¬ 
able truth in them, but should not be used 
as an excuse to neglect the users’ needs. In 
the final analysis, users are the ones who 
best understand their requirements and 
are the best judges of whether a particular 
implementation of these requirements 
meets operational needs. Proper design of 
the system to meet functional and perfor¬ 
mance characteristics and to support, at a 
reasonable cost, future system mainte¬ 
nance and evolution is necessary, but the 
most important objective for the ATC 
automation system design is that it allow 
the air traffic controllers to do their jobs 
safely and effectively. In recognition of 
the fact that the computer system must be 
an integral component of the total man- 
machine system needed to perform air 
traffic control, the FAA has made man- 
machine interface, or MMI, concerns a 
central part of the program, from initial 
functional and performance requirements 
definition, through hardware/software 
design and prototype test and evaluation, 
to final system implementation. To ensure 
that the user needs will be met, controllers 


are playing a critical role in this entire 
process. 

The man-machine interface design will 
determine the way in which the controller 
and the machine are going to work togeth¬ 
er to provide safe and efficient air traffic 
control. “Machine” in this context refers 
to both the sector suite console (consisting 
of displays and input devices) and the 
computer hardware and software that im¬ 
plement the interaction language by which 
the controller and ATC automation sys¬ 
tem communicate. The rest of this section 
presents an overview of the FAA’s ap¬ 
proach to the man-machine interface and 
particularly to the role of the air traffic 
controller, our user, in the process of re¬ 
quirements definition, design, and test. 
Other articles in this issue will provide con¬ 
siderably more detail. 

The objective of the requirements 
definition process was to develop a com¬ 
plete set of requirements that truly reflects 
the needs of the controller, that captures 
what works well in today’s ATC system, 
and that takes advantage of the advances 
that have been made in MMI technology 
over the past two decades. The MMI re¬ 
quirements are stated in terms of function 
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and peformance. That is, they state what 
information must be exchanged between 
the computer and the controller to carry 
out a particular task effectively. The 
details of the MMI “language,” that is, 
how information is entered into the com¬ 
puter and how information is displayed, 
are the responsibilities of the system 
designer. To allow the designer to op¬ 
timize the MMI, the requirements were ac¬ 
companied by a complete description of 
the tasks that make up the ATC job. Any 
task dependencies and paralleUsm are in¬ 
cluded in this description. We call this the 
AAS MMI operations concept. Finally, a 
specification of the sector suite console 
(the hardware that makes up the controller 
workstation) accompanied the MMI lan¬ 
guage requirement and the operations 
concept. 


Over the past three years, the FAA has 
developed three documents that capture 
this overall MMI requirement. They are 

• Operations Concept for the Man- 
Machine Interface, 

• Sector Suite Man-Machine Func¬ 
tional Capabilities and Performance 
Requirements, ^ and 

• Sector Suite Console Requirements 
Specification.'* 

The three documents have been delivered 
to the two AAS design contractors, 
Hughes Aircraft Corporation and IBM 
Federal Systems Division, where they are 
being used, together with the AAS System 
Level Specification, 5 to competitively 
develop total AAS designs and sector suite 
console prototypes. 

The FAA Air Traffic Service, or AAT 
(i.e., the “user” of the system), and the 


Advanced Automation Program Office, 
or AAPO (the engineering organization 
responsible for the AAS), established a 
cooperative mechanism for defining these 
requirements and ensuring their im¬ 
plementation by the AAS contractor. The 
AAT formed the Sector Suite Require¬ 
ments Validation Team, or SSRVT, to 
identify and validate the sector suite con¬ 
sole and man-machine interface language 
requirements. The SSRVT is made up of 
five en-route controllers, five terminal 
controllers, two air traffic managers, and 
three regional representatives. AAPO 
serves as the facilitator to assist the team in 
developing a consistent and complete 
statement of the requirements in a manner 
suitable to begin console and language 
design. This was achieved through use of a 
dedicated 10-person multidisciplinary 


Air traffic control today and tomorrow 


To understand the problem of 
design and development of an ATC 
computer system, it is important to 
have a good grasp of what the generic 
role of an ATC system is, how that 
role is carried out today, and how we 
envision the way this role will be car¬ 
ried out in the future. 

Generic description of air traffic 
controi. ATC can be characterized in 
terms of a closed-loop control theory 
model consisting of the following 
functional elements; 

(1) A planning function that for¬ 
mulates the desired state of the 
system based on a set of goals. 

(2) A controlling function that 
estimates deviations between the 
observed, predicted, and desired 
states of the system and formulates 
those actions necessary to minimize 
the deviations and then transmits 
those actions to the appropriate 
system elements. 

(3) A system function thafi consists 
of all the major system elements. Cer¬ 
tain of these elements execute the 
control actions received and are sub¬ 
ject to such external disturbances as 
weather, pilotage error, equipment 
outages, etc. Others simply function 
as aids to allow/assist in execution of 
the required control actions. 

(4) A data managing function that 
observes and records the system 
state and distributes this information 
to planning and controlling functions. 


This model (see figure below) is 
useful in the ATC context where the 
term “planning” is understood to in¬ 
clude system-wide needs for smooth 
traffic flow, fuel-economic flight, etc., 
and “control” is understood to ad¬ 
dress short-term tactical problems in 
executing the plan while providing 
safe separation of aircraft. 

Today the basic planning and con¬ 
trol responsibility is with the air traffic 
controller. The computer supports the 
controller, primarily through manipu¬ 
lation and display of radar and flight 
data. As ATC evolves during the life of 
the AAS, more and more of the func¬ 
tions in the domain of the human will 
migrate to the domain of the automa¬ 
tion system. Research is under way at 
FAA to determine how this migration 
should be engineered and what the 
relative roles of man and machine 
should be in each step along the way. 

ATC system of the 1980’s. At the 
national level, the ATC system of to¬ 
day has as its primary inputs informa¬ 
tion about the projected flight path, 
departure time, aircraft identification 
and type (caiied a flight plan), informa¬ 
tion about nationwide traffic levels, 
airport capacities, and weather infor¬ 
mation. A central flow control facility 
has been buiit to perform the national 
planning and control functions. 

At the en-route level, inputs consist 
of weather information, surveillance 
information from both primary radars 


and from the airborne ATC radar bea¬ 
con system, or ATCRBS, flight plans 
forwarded from departure airports or 
adjacent en-route centers, flow man¬ 
agement instructions from the central 
flow control system, and acceptance 
rates from terminal areas. 

Planning and control in today’s 
ATC centers are done by two- to 
three-person ATC teams. Each team 
is responsible for a fixed, three- 
dimensional piece of airspace called a 
sector. Typically, a sector contains 
seven to 10 aircraft. The controller, 
with the assistance of the ATC com¬ 
puters, generates commands (called 
clearances) that he or she transmits 
to the pilot via radio to ensure 
confiict-free and expeditious flight 
along the route specified in the flight 
pian. 

Today the primary functions of the 
en-route computer complex are radar 
data processing, or RDP, and flight 
data processing, or FDP. RDP takes 
inputs from many surveillance sites, 
performs tracking on these, associ¬ 
ates the tracks with flight plans, and 
presents a composite, all-digital 
display of surveillance and aircraft in¬ 
formation to the controller. Normally 
there is one display per sector. 

The system must present this infor¬ 
mation to the controller no more than 
two seconds after receipt of surveil¬ 
lance information. FDP accepts flight 
plan information, and, as the aircraft 
flies through a center’s airspace, up- 
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team (computer scientists, human factors 
experts, engineers, and ATC experts). 

To ensure that these products capture 
the AAT operational requirements and 
serve as the foundation for the subsequent 
man-machine interface design process, a 
rigorous methodology, based on the MM/ 
Design Guide Book developed at TRW in 
1981, W21S adopted. ® This guide book was 
adapted and refined by Computer Tech¬ 
nology Associates, Inc., for development 
of the operations concept, sector suite 
console requirements, and controller 
MMI language requirements. 

While the analytic work in this method¬ 
ology was carried out by the multidisci¬ 
plinary team, the SSRVT was an integral 
and active participant in the engineering 
process. The SSRVT provided extensive 
support in the definition of the ATC job. 


in the process of allocating functions to 
the machine, and finally in the validation 
of the requirements. This 15-person team, 
in addition to carrying out its normal 
duties, spent a total of 10,(XX) hours on this 
activity over an 18-month period. The suc¬ 
cess in the development of the three major 
documents and their accuracy in capturing 
the ATC job are directly attributable to 
the complementary activities of the 
engineering and user groups involved. 

In August 1984, the FAA awarded two 
3-'/2-year competitive contracts, each on 
the order of $200 million, for the total 
AAS design and the development of a sec¬ 
tor suite console prototype. The design 
and development of the AAS MMI will be 
an integral part of the total AAS design 
process. In addition to a series of contrac¬ 
tually required MMI-related studies, the 


prime contractors will be responsible for 
MMI presentations at the design reviews 
up through the critical design review. 
While not required contractually, both 
contractors, it is anticipated, will use some 
form of MMI test bed to perform design 
trade-offs. The console prototype devel¬ 
opment will include console mock-ups, 
data entry and display service demonstra¬ 
tions, and finally a three-month console 
prototype demonstration. This demon¬ 
stration will take place before any 
operational software is developed and, 
therefore, will be based on specifically de¬ 
veloped demonstration software rather 
than a complete MMI function capability. 

After this design competition phase the 
current plan calls for one of the two con¬ 
tractors to be selected for full production 
of AAS software, hardware, and sector 


dates this information and prints 
flight progress strips at appropriate 
sector positions. There are provisions 
for entering new and revised flight 
data at all operational positions. The 
en-route computers provide the 
means for Intersector coordination 
and interfacility coordination through 
use of computer-transmitted data. 
This allows aircraft to be “handed 
off” from one controller to another. 
The computer generates displays of 
geographic maps and outlines of 
severe weather areas. 

1 One of the interesting aspects of 
this system is that most of the impor¬ 
tant information about aircraft has 
been digitized and can be convenient¬ 
ly sent over a standard telephone 
channel using modern digital modems. 
Even the wide-band analog from the 
primary radars is handled this way in 
the en-route environment and at some 
terminal sites. It is possible today and 
will be common in the next-genera¬ 
tion ATC automation system to have 
the output of a terminal radar at a ter¬ 
minal radar approach control, or 
TRACON, presented in display form 
at both the airport and the en-route 
center. This will allow consolidation 
of terminal area radar control into the 
en-route center and thereby will per¬ 
mit more efficient use of the airspace 
and personnel. Hand-offs in busy 
areas such as metropolitan Los 
Angeles and New York will be facili¬ 
tated. The ease of sending digital data 
to several locations makes possibie a 


new level of redundancy in the na¬ 
tional system that would have been 
extremely expensive, if not impossi¬ 
ble, in the earlier days of analog 
systems and before the existence of 
high-performance modems. 

ATC system beyond 1995. Beyond 
1995, we expect that many of the 
pianning and control tasks performed 
today by the controller will migrate to 
the computer. By increasing the num¬ 
ber of control processes that are 
automatically performed, the control¬ 
ler’s job will shift from traffic data 
handling to traffic management. Ini¬ 
tially the machine will assist the con¬ 


troller in the actual clearance genera¬ 
tion function. Later the computer will 
generate clearances that can be 
directly transmitted to aircraft via a 
data link. Today, ATC computers sim- 
piy manipuiate data for presentation 
to controllers. In a highly automated 
environment, the machine will be 
characterized by its ability to analyze 
data and determine what actions are 
needed to achieve a desired system 
state. The controlier will be responsi¬ 
ble for determining the general health 
of the automated system, for handling 
exceptions, and, in the rare case of 
failures of the automated system, for 
coordinating backup plans. 


Planning Controlling System 

errors errors disturbances 



errors 

Control system functional block diagram. 
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ATC automation system characteristics 


To grasp the objectives for the AAS 
design one must understand the 
basic characteristics of the ATC com¬ 
puting system. It is a system that is 

(1) large—on the order of 1 million 
source lines of application code 
and between 500,000 and 1 mil¬ 
lion source lines of support 
code; 

(2) complex—numerous interacting 
functions and many different ex¬ 
ternal interfaces; 

(3) quasi-real-time—delays in 
presentation of aircraft surveil¬ 


lance data and conflict alerts im¬ 
pact system safety; 

(4) highly available—because con¬ 
troller dependence on the com¬ 
puter is high, failures degrade 
ATC efficiency and safety; 

(5) highly reliable—as more of the 
control responsibility is trans- 
fered to the computer, error con¬ 
tainment becomes imperative; 
and 

(6) highly interactive—the con¬ 
troller uses the automation sys¬ 
tem as an integral participant in 
the ATC process. 


suite consoles. Approximately 1-2 years 
after the production award, a complete 
system will become available at an FAA 
test facility for extensive MMI refinement 
and operational testing. After systems are 
installed at FAA field facilities, it is 
planned to use the systems for a year of ad¬ 
ditional operational testing and controller 
training prior to placing the new man- 
machine interface into operational use. 
These steps, all of which involve active 
user participation, are believed to be 
essential to the continued safety of ATC 
during the transition to a new controller 
workstation and MMI. 

The benefits of user participation dur¬ 
ing the design competition and later, dur¬ 
ing operational system testing, depend to a 
large extent on the user’s understanding of 
the requirements and on the continuity of 
user involvement. For that reason, the 
SSRVT will remain intact until the new 
MMI is ready for implementation. The 
SSRVT will be supported by the multidis¬ 
ciplinary team to help them understand 
the contractor-developed technical reports 
and design specifications and to support 
them in the test and demonstration 
activities. 

During the design competition phase, 
the primary SSRVT responsibilities will be 
to review trade studies and design docu¬ 
ments; to review test/demonstration plans 
and procedures; and to evaluate mock- 
ups, data entry and display devices, and 
console prototypes. The team will be con¬ 
cerned with whether or not the specifica¬ 
tion and the user (i.e., operational) re¬ 
quirements are met by these products. The 
SSRVT will also be responsible for assess¬ 
ing the user impact of proposed MMI- 
related specification changes. 


During the acquisition phase, the 
SSRVT will form the core of a larger con¬ 
troller group that participates in the func¬ 
tion/algorithm evaluation, MMI language 
refinement, integrated system validation, 
and operational evaluation. This group 
will be concerned with whether or not the 
system meets operational needs and is 
suitable for controller transition. 

In summary, we believe that this em¬ 
phasis on the MMI is necessary to continue 
the safe and efficient flow of air traffic as 
the FAA carries out the transition to the 
next-generation ATC automation system. 
As the AAS evolves, the FAA will control 
changes to the MMI through continued 
use of the formal MMI methodology and 
corresponding changes to the baselined 
MMI documents. In this way, we expect to 
maintain the efficiency/effectiveness of 
the MMI and avoid the safety hazards that 
could result from less carefully planned 
changes in systems that depend on the 
critical interaction between man and 
machine. 

Designing for reliability 
and safety 

Introduction. High system availability 
is the characteristic that, in the past, has 
represented the greatest difference be¬ 
tween the FAA systems and commercially 
available systems. Both the terminal 
ARTS III and NAS 9020 computers con¬ 
tain special design features to permit rapid 
detection of failed units and automatic 
reconfiguration of the remaining units to 
provide continuous operation. The same 
design philosophy was followed in the 
design of the en-route display channel. 


The late-1960’s technology available when 
the display system was designed dictated 
centralized display drivers rather than the 
smart displays being produced today. 
Thus, the display channel consists of a 
fault-tolerant computer that contains the 
refresh memories for all displays. Similar¬ 
ly, character/vector generators are cen¬ 
trally located where automatic switching 
to redundant units can take place. 

Despite the design for fault tolerance in 
the current en-route computers and dis¬ 
play channel, there are (infrequent) hard¬ 
ware and software failures that cause a 
total computer system outage. To ensure 
continuity of air traffic control services, all 
centers also have a broadband radar data 
backup system that can bypass the central 
computer and display channel and provide 
a raw radar image on the controller’s 
display. Greater dependence on the digital 
ATC displays with their alphanumeric an¬ 
notation led to the development of DARC, 
an independent minicomputer-based 
backup channel that can provide the 
displays with processed and annotated 
radar situation display data. 

Near-term considerations. In the early 
1990’s controllers will still be the primary 
agents for planning and control, but their 
dependence on the computer will increase 
as safety aids (conflict alert, minimum safe 
altitude warning) and planning aids (en- 
route metering, conflict resolution) are 
added to the computer systems. Thus the 
computer systems that replace the 9020’s 
will have to provide an availability level 
approaching 1. 

On the surface it would appear that this 
high availability requirement could be met 
by using adjacent facilities to back up each 
other, but for a number of reasons this 
does not appear to be a viable alternative. 
Backup could be achieved by taking over 
full ATC, including controller functions, 
or by providing computer backup only. In 
the first case, staffing cost to keep enough 
controllers on hand for backup and train¬ 
ing cost to keep backup controllers 
familiar with the airspace of other centers 
are excessive. In the second case, switch¬ 
over leads to service disruptions that 
would be too lengthy to be acceptable to 
controllers and the aviation community. 
Thus, the FAA must build as much availa¬ 
bility as possible into the computer system 
at each center. 

A goal is to build a system that can pro¬ 
vide correct and sufficient data to con¬ 
trollers whenever it is needed. This clearly 
requires carefully designed redundancy. 
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fault detection, and automatic recon¬ 
figuration. On-line automatic diagnosis 
and location of faults to the smallest 
replaceable module are essential. Replace¬ 
ment of failed units must be done while the 
system is operating without interrupting 
the program or affecting the quality of the 
data presented to the controller. Also, the 
checkout of new software releases must be 
done while the old system is running. 

An area of particular concern to the 
FAA is the detrimental effect that software 
errors could have on availability. Progress 
has been made over the past decade in 
software engineering and application of 
successful techniques will contribute to 
software correctness, but that is not 
enough to meet ATC automation needs. 
Robustness must be built into the func¬ 
tionality of the system—for example, one 
might augment application code with 
context-sensitive checks on the reason¬ 
ableness of the results of individual mod¬ 
ules. As the design of FAA’s future com¬ 
puter system progresses, the structure of 
the hardware and software systems will be 
carefully examined in light of their system 
failure vulnerability. 

Evolutionary considerations. In the 
ATC system of the late 1980’s and early 
1990’s, final responsibility for each ATC 
clearance lies with the controllers. In car¬ 
rying out that responsibility, they work 
closely with the computer system and are 
able to detect and compensate for faults 
not detected by the computer system. As 
planning and control functions migrate to 
the computer system, this safety buffer 
provided by controllers will begin to disap¬ 
pear and fault tolerance of the computer 
system becomes more critical. 

Error detection and isolation must be 
improved. Greater software correctness, 
perhaps through proofs of critical mod¬ 
ules, will be required. Robustness of the 
automated planning and control process 
will have to be introduced. For example, 
one could provide protection against the 
hazard that may result if a pilot overshoots 
an assigned altitude by having the auto¬ 
mated system look beyond the assigned 
altitude before issuing an altitude change 
clearance to the pilot. If it is determined 
that a conflict would result from an 
altitude “bust,” the computer can post¬ 
pone the clearance. The safety of auto¬ 
matically generated clearances can be 
checked by independent software and per¬ 
haps even hardware before delivery to the 
pilot. Safety of the control process can be 
enhanced by providing a collision-avoid¬ 


ance system that operates independently 
of the ground-based computers and con¬ 
trollers. Such a backup system, called the 
Traffic Collision Avoidance System or 
TCAS, is being developed by the FAA. 

AAS Strategy. The FAA’s approach to 
the AAS is to require very high availability 
for the full set of functional capabilities. 
Today’s state of the art in software and 
hardware technology cannot guarantee 
that there will be no errors; therefore, this 
strategy is augmented by a requirement to 
provide error detection and recovery of in¬ 
dividual functions. From an operational 
viewpoint, how long a recovery period can 
be tolerated varies from function to func¬ 
tion. Controllers can, for example, con¬ 
tinue their job if flight data is not im¬ 
mediately restored, but they need radar 
data at all times. Therefore, functional 
recovery times have been specified on the 
basis of the time criticality of a particular 
function. 

An analysis of ATC shows that there is a 
minimum set of functions that are abso¬ 
lutely necessary if controllers are to con¬ 
tinue their job. Today that capability is 
provided by DARC and manual manipu¬ 
lation of flight progress strips (e.g., sort¬ 
ing, marking, and handing to controllers 
in adjacent sectors). For the AAS, we have 
specified an emergency mode of operation 
that provides these particular functions 
and that has a very high probability of 
being available when needed. Further¬ 
more, this mode can be activated separate¬ 
ly by each controller, on the basis of his or 
her judgment of whether normal service 
has degraded to the point where it hampers 
the controller in carrying out his or her 
particular activities. 

For the case when there are more 
resources than required by emergency 
mode, but not enough for full system 
operation, FAA has rejected the tradi¬ 
tional requirement for a fail-soft strategy* 
and has specified error detection and 
recovery instead. The reasons for this are 

(1) the very high availability of the full 
service mode makes the need for fail-soft a 
rare event; 

(2) a fail-soft strategy is generally quite 
costly and it appears that error detection 
and recovery will be a better investment; 
and 

(3) depending on the system architec- 


* A fail-soft strategy calls for allocating available system 
resources on a priority basis. Thus, as hardware 
elements are lost, the remaining elements are recon¬ 
figured to delete the less critical functions. 


ture, a fail-soft strategy could be incom¬ 
patible with a design that is well suited for 
recovery. 

No matter how painstakingly one 
designs, builds, and tests a system, there 
will be the inevitable occurrence of “Mur¬ 
phy’s law.” If a center failure occurs, ad¬ 
jacent facilities will be used to maintain 
contact with pilots, and ATC computers 
at these facilities can provide emergency 
assistance to the backup controllers at 
these “backup” facilities. While it may be 
necessary to divert aircraft from their in¬ 
tended course and efficiency of operations 
might be impaired, a facility backup 
scheme incorporated into AAS, while not 
providing full ATC service, will be able to 
preserve safety in the case of catastrophic 
facility failures. 

The reliability/maintainability/availabil¬ 
ity requirements in the AAS System Level 
Specification set goals for the system 
assuming that very complete fault toler¬ 
ance provisions are made in the design. 
Availability goals are set with the expecta¬ 
tion that system recovery management will 
always remain in control, but that some 
exceptionally difficult recovery sequences 
will reduce the services that remain avail¬ 
able to the controllers from the standard 
“full service mode” to those defined as 
“reduced capability mode” and “emergen¬ 
cy mode, ’ ’ respectively, for short periods of 
time. 

This poses an interesting challenge to 
the designer of a distributed computing 
system such as the AAS. He or she must be 
able to balance the operational impact of 
failures in a particular design against error 
detection and recovery strategies and 
against the predicted reliability “numbers” 
of a design option. Because it is impossible 
to quantify all of the relevant variables in a 
functional specification that will be real¬ 
ized by a distributed design, the judgment 
of the designer must be tempered with the 
judgment of the system user to arrive at a 
reasonable design solution. 

However unlikely, there exists the possi¬ 
bility of a “collapse” of the system 
recovery management capabilities. This 
may lead to the failure of the central por¬ 
tion of the system. In this event air traffic 
control would revert to emergency mode 
operations and manual methods to avoid 
any impact on system safety. The pre¬ 
viously discussed “facility backup” by ad¬ 
jacent ATC centers is provided to main¬ 
tain safety in the case of natural disasters 
such as floods and earthquakes. 

The near-100 percent availability of the 
system is attainable through the pursuit of 
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the following three goals: 

(1) sufficient hardware redundancy to 
avoid system outages due to hardware 
outages; 

(2) complete, protected, and sufficient¬ 
ly fast fault detection and recovery 
algorithms for every anticipated class of 
faults within the system in order to provide 
near unity fault coverage; and 

(3) error detection, containment, and 
recovery features in the system and ap¬ 
plication software to provide fast-reacting 
defenses against the consequences of hard¬ 
ware failures and of residual software 
defects. 

The successful introduction of these RMA 
attributes requires continued analysis, 
modeling, and testing throughout the 
entire design process. A sequence of 
refinements will be based on the results. 
The refinements will lead to continuing 
growth of system reliability toward the 
goals contained in the AAS System Level 
Specification. 

As the development of the hardware 
and software element progresses, testing 
becomes critically important. The system 
should be subjected to as many failure 
modes as possible and the behavior under 
stress must be explored. Finally, the sys¬ 
tem must be thoroughly tested in a realistic 
environment to ensure that the system can 
support the user under normal and failure 
conditions without impact on ATC safety 
and that the system can be maintained. To 
support this test program, the FA A has 
established a comprehensive test environ¬ 
ment at the FAA Technical Center in At¬ 
lantic City, New Jersey. AAS testing of 
over a year at this facility will be supported 
by development contractors, FAA engi¬ 
neers and software specialists, and con¬ 
trollers and maintenance personnel 
brought in from key field sites. FAA ex¬ 
perience has shown that even this extensive 
test program will have to be augmented 
with a thorough shakedown at each field 
site. Finally, to guarantee ATC safety, the 
system will be introduced into operation 
gradually, beginning during low activity 
periods and slowly extending to the busy 
hours as confidence in the system in¬ 
creases. 

In summary, achieving the RMA char¬ 
acteristics necessary for conducting air 
traffic control safely from the day of sys¬ 
tem introduction through a long system 
evolution requires a great deal of discipline 
starting with requirements definition and 
continuing through design, development, 
system testing, and finally operational 


implementation. System safety must be a 
major concern throughout and a reliabili¬ 
ty growth program is absolutely neces¬ 
sary. But, as with all large systems, suc¬ 
cess is dependent on the cooperative 
efforts of designers, developers, users, 
and maintainers. 


Designing for a long 
system life 

The Investment in time and money 
(estimated $2-3 billion) to design and im¬ 
plement a new ATC automation system 
dictates a long system life. The current 
automation systems will have been in ser¬ 
vice over 20 years when they are replaced 
by the Advanced Automation System, and 
there is no reason to suspect that the basic 
AAS system design and software will not 
have a 20- to 30-year life span. 

Such a long system life places some dif¬ 
ficult demands on the system designer. 
From the discussion in the previous sec¬ 
tions, it should be apparent that the ATC 
environment is continually evolving. The 
functions to be performed by the com¬ 
puter system (and, therefore, the man- 
machine interface), the external data 
sources (aircraft surveillance systems, 
weather sensors, navigation systems, etc.), 
as well as the traffic levels, air fleet mix, 
aircraft jjerformance characteristics, and 
avionic capabilities all change over time. 
The AAS designers must ensure that this 
evolution can be accommodated at a 
reasonable cost and without detrimental 
impact on system (hardware and software) 
reliability and on the critical man-machine 
interface design. 

A second demand on the system design¬ 
er that stems from the long system life ex¬ 
pectancy is the need to accommodate, 
without significant system perturbation, 
upgrades of hardware technology. This re¬ 
quirement stems from the fact that today’s 
computer generations for large commer¬ 
cial systems last for 4-7 years and even less 
in the rapidly expanding microprocessor 
area. Government and industry experience 
in the last decade has shown that cost- 
effective computing, from a total life cycle 
cost viewpoint, is best achieved by a well- 
defined capacity management program 
that permits upgrades as demand increases 
or as a hardware generation is superseded. 
Without an AAS design that permits hard¬ 
ware upgrades, the initial computer hard¬ 
ware installed will have to be sized to handle 
the largest projected demand for traffic 


and functional growth throughout the sys¬ 
tem life. In addition to “overbuying,” this 
would result in unacceptably high mainte¬ 
nance costs (for 20- to 30-year-old technol¬ 
ogy) by the end of the system’s life. 

The strategy selected by FAA to meet 
these unique requirements puts extensive 
focus on system design in the early part of 
the program. Clearly, the basic system 
design, in terms of both hardware and 
software structure, will have to remain in¬ 
tact for the total system life. The software 
is expected to be augmented and modified 
as the system evolves, but, except for 
isolated modules, no software replace¬ 
ment is planned. The hardware will be 
upgraded or replaced on a module-by- 
module basis as dictated by a capacity 
management strategy and by maintenance 
cost considerations. 

The FAA has required that the system 
be designed around a local communica¬ 
tions network (with the requisite reliability 
characteristics) based on local area net¬ 
work technology and industry-accepted 
protocol standards. This will allow the in¬ 
troduction of new hardware technology 
without major system perturbations. To 
complement the hardware strategy, soft¬ 
ware will be functionally distributed and, 
perhaps more importantly, developed in a 
single high-order language (most likely 
Ada) that permits easy migration from one 
processor to another. An important crite¬ 
rion in the evaluation of this life cycle stra¬ 
tegy will be the impact of change on system 
stability since the ATC application cannot 
tolerate degradation in system reliability 
and availability during and after a change. 

Another important ingredient in achiev¬ 
ing our objectives will be strict adherence 
to standards, the careful control of the 
system (hardware and software) configur¬ 
ation, and careful interface manage¬ 
ment—throughout the system life. The 
top (system) level specification provided to 
the AAS contractors is a functional and 
performance specification (A-level) that 
conforms to MIL STD 490.^ The FAA 
has selected MIL STD 2167* for the suc¬ 
cessive baselines that document the system 
design and implementation. This empha¬ 
sis on configuration and requirements 
management will be complemented with 
extensive independent verification and 
validation and a carefully structured test 
and evaluation program that places a 
heavy weight on the operational suitability 
of the system. 

Following the above strategy and apply¬ 
ing computer science and software engi¬ 
neering principles of the 1980’s will help 
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achieve the extensibility characteristics 
necessary for a successful long system life, 
but this is not enough. If a system with the 
stringent performance and reliability 
characteristics of the ATC system is to 
evolve in a cost-effecteve manner, the ini¬ 
tial system designer must be able to an¬ 
ticipate the most likely course of evolution 
and the nature of the changes that can be 
expected. For example, the input/output 
structure should anticipate data attributes 
that might become important as more of 
the ATC decision-making responsibility is 
shifted to the computer. The problem for 
the system designer arises from the fact 
that no firm requirements for the system 
interfaces of functions anticipated for the 
late 1990’s and beyond exist at this time. 

To help add the proper evolutionary 
characteristics to the system design, the 
FAA developed a functional and perfor¬ 
mance description of what, to the best of 
our knowledge, a highly automated ATC 
system would be. This description places 
particular emphasis on how the advanced 
functions might interface with the ATC 
computer system that will actually be built 
by the AAS contractors and that will form 
the starting point for future evolution. 
The AAS system designers are contrac¬ 
tually required to show FAA, at various 
stages of system design and development, 
how their particular design can be ex¬ 
tended to accommodate these likely future 
functions. 

Table 1 provides a summary of the de¬ 
sign considerations presented in this section 

Acquisition strategy. In any large gov¬ 
ernment procurement, the strategy se¬ 
lected for system acquisition has a signifi¬ 
cant impact on the nature and schedule of 
technical activities. Generally, the govern¬ 
ment develops a program plan, writes a 
functional specification and associated 
documents (including a master test plan), 
and lays out a statement of work that iden¬ 
tifies the development strategy (and often 
methodology). The contractor is generally 
responsible for system design, develop¬ 
ment, and integration/implementation. 
The government monitors these activities, 
approves contractor products such as 
design specifications and production 
specifications at predetermined mile¬ 
stones, and, finally, accepts the system 
and any associated training, documenta¬ 
tion, and logistics support system. The ac¬ 
quisition strategy must be tailored within 
this general framework of responsibility to 
meet the major program objectives. In the 
FAA’s case, the major objectives were to 


Table 1. AAS design considerations. 


Requirement 

Benefit 

Design around a local communication 
network 

Design based on existing local area net¬ 
work technology and industry- 
accepted protocols permits future 
replacement, upgrade, or addition of 
computer hardware components 
without major system perturbation. 

Functional distribution of software 

Distributed design supports high 
availability concepts and facilitates 
functional evolution because of 
discipline imposed by partitioning. 

Modern high-order language, or HOL 

Use of standard, widely accepted HOL 
permits easy migration from one pro¬ 
cessor to another. 

Adherence to standards, configuration 
control, and interface management 

Emphasis and strict adherence in these 
areas will support orderly hardware 
and software change. 

Independent verification and 
validation, or IV&V 

IV&V provides an insurance policy that 
requirements are met and that the 
design is implemented correctly. 

Demonstrate extensibility of design, 
including ability to handle likely 
future functions and interfaces 

Ensures cost-effective system evolution. 


achieve the best possible design that meets 
the requirements discussed earlier in this 
article, to minimize the investment cost 
and the overall life cycle cost, to maintain 
schedule, and to foster the use of innova¬ 
tive hardware and software technology. 

FAA decided that the phased implemen¬ 
tation of the AAS will be carried out in two 
separate but parallel procurements. The 
first procurement is for the design and im¬ 
plementation of the host computer sys¬ 
tem, or HCS. The second (parallel) pro¬ 
curement is for the new system design and 
the staged implementation of the full 
AAS, starting with the initial sector suite 
system (ISSS) and ending with the new 
tower control equipment and the advanced 
automation functions. 

The program was separated into these 
two procurements because the objectives 
and nature of the two are quite different. 
The major objective of the HCS is to pro¬ 
vide additional en-route capacity by 1987. 
The HCS contractor was provided with an 
explicit definition of where and how the 
new computer system must interface with 
existing FAA equipment and his major 
task is to make the existing software work 


on the new computer with minimal 
change. The HCS is a relatively short pro¬ 
gram, with initial operation of the HCS 
scheduled for only 3-4 years after initial 
contract award. 

On the other hand, the AAS contrac¬ 
tors’ primary concern during the first 31/2 
years is to develop a new design that will be 
suitable for the long projected life of the 
AAS. The AAS contractors were provided 
with a high-level statement of what the 
AAS must do (a functional and perfor¬ 
mance system level specification), and it is 
their responsibility to decide precisely how 
the system will do the job. The AAS is a 
long-range program, with different in¬ 
crements becoming operational up to 10 
years after contract award, respectively. 
The two separate procurements for HCS 
and AAS allowed the FAA to select in¬ 
dustry teams best suited for each of these 
two very different types of activities and 
avoided conflicts in priorities between 
achieving early host implementation and 
developing the best possible AAS design. 

The FAA is using a two-part procure¬ 
ment consisting of an initial design com¬ 
petition by two contractors followed by an 
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acquisition award to one of the two for full 
production for both the HCS and the 
AAS, but for different reasons. A design 
competition was selected for the HCS to 
minimize the risk that the HCS would not 
be ready for operation by 1987. The task 
of rehosting requires very specific talents, 
particularly in understanding the NAS 
softare monitor (that part of the software 
that controls the computer system as op¬ 
posed to the application software that car¬ 
ries out the ATC functions). During the 
design competition phase, the two host 
contractors demonstrated their ability to 
perform this technically intricate rehosting 
job. The cost competition for the relative¬ 
ly large computer hardware buy took place 
after this ability had been demonstrated, 
and, therefore, the risk of failure to 
migrate successfully the NAS software to 
the host was very low. If the FAA had 
chosen to select a single contractor at the 
outset of the procurement, the selection 
would have been heavily weighed by the 
hardware cost, thereby possibly allowing a 
contractor without the necessary demon¬ 
strated technical ability to “buy in ” with a 
low price and later fail technically. 

A design competition was chosen for 
the AAS procurement for the reasons em¬ 
bodied in the OMB A-109 acquisition.’ 
The FAA fully supports the objective of 
taking advantage of the capabilities and 
ingenuity possessed by the US computer 
industry and believes that the AAS design 
competition is the best way to achieve this 
objective. The FAA selected the two con¬ 
tractors, not in the traditional manner 
where proposed designs are evaluated, but 
on the basis of the contractor’s methodol¬ 
ogy and approach to carrying out the AAS 
design effort. This avoids a frequent ac¬ 
quisition problem of premature commit¬ 
ment to a design that was hastily devel¬ 
oped in a short proposal phase. Each of 
the two contractors is developing a com¬ 
plete AAS design, including the subset of 
AAS required for ISSS. The FAA will 
select one of the two for full system ac¬ 
quisition based on technical, manage¬ 
ment, and cost proposals. The FAA 
believes that the emphasis on design, 
coupled with the competitive nature of the 
design process, will achieve the major ob¬ 
jective of a cost-effective long system life 
for AAS. 


It should be evident that while the con¬ 
cerns cover a broad spectrum, they also 
have many interactions. Success of the 
critical national program depends on un¬ 
derstanding the risks and careful planning 
to minimize risks. Requirements must be 
carefully managed and trade-offs between 
the major requirements identified in this 
article will have to be approached carefully 
to control cost, schedule, and technical 
risks. Rigor in design methodology and 
system validation must be maintained. 
Finally, a focus on the real problems of 
building a system for the users of transi¬ 
tion without impact on ATC safety and ef¬ 
ficiency must be maintained at all times 
through user involvement and an under¬ 
standing of the ATC job and ATC system 
environment. □ 
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Complex system- 
architecture 
evaluation is a 
business fraught with 
many perils. The FAA 
seeks to minimize 
these perils by 
pursuing a broad 
range of architectural 
analyses. 


T he Advanced Automation System 
(AAS) of the US Federal Aviation 
Administration (FAA) will be a 
very large, complex, real-time system for 
data acquisition, processing, and storage.' 
It will interact with the user extensively 
and with a high degree of responsiveness, 
and it has a planned operational life of 20 
to 30 years.' 

The procurement of the AAS will be ac¬ 
complished in two parts; the design com¬ 
petition phase (DCP), which is under way, 
and the follow-on acquisition phase (AP), 
for which the proposal submittal process 
will begin in early 1988. The prime con¬ 
tractors chosen to submit designs during 
the DCP were picked for their proposed 
design methodologies (rather than in the 
more usual ways), and will be the sole 
competitors bidding for the AP. Selection 
of one contractor to implement the AAS 
during the AP will be based partially on 
the availability, extensibility, and length of 
system life attributes characterizing the ar¬ 
chitectures submitted during the DCP. 

A major purpose of the DCP is to ob¬ 
tain from each of the two contractors both 


a competitive, detailed exploration of the 
contractor’s reasons for selecting a specif¬ 
ic system architecture for design and im¬ 
plementation, and suggestions for compo¬ 
nent hardware and software that would 
satisfy not only the present requirements, 
but also the growth and extensibility needs 
that will be posed by future air traffic con¬ 
trol (ATC) functions. 

One of the difficult questions the FAA 
must address during the DCP is how one 
can determine the degree to which a prime 
contractor’s system architecture meets re¬ 
quirements. This process of determination 
is different from the FAA’s technical 
evaluation of the proposals for the acqui¬ 
sition phase; it is also different from the 
evaluation and testing of the system archi¬ 
tecture that will be conducted by the prime 
contractor during the AP. 

(In this article, we use the term “system 
architecture” to describe the composition 
and organization of computers, controller 
workstations, local area network commu¬ 
nications, and external communications 
that constitute the Advanced Automation 
System. “System architecture” refers also 
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to both the composition of partitioned 
software components that are allocated to 
the various computers and workstations 
and to the architecture for achieving fault 
tolerance, error detection, and recovery 
coverage.) 

A fundamental concern of the FAA, 
then, is to evaluate an architecture while it 
is still on paper, to understand the implica¬ 
tions of that architecture’s implementa¬ 
tion, and to challenge the contractor’s 
technical decisions wholly from a re¬ 
quirements standpoint. This raises an issue 
that must not be overlooked: The FAA 
chose not to provide design guidance, 
since that would violate the critical tenet 
that this is a design competition. The 
FAA’s analysis of the architecture while 
the architecture is still on paper will be the 
method whereby inadequacies in meeting 
requirements are discovered; the analysis 
will thus provide the review necessary to 
achieve a quality design. 

The FAA’s approach to architecture 
analysis, which is presented in this article, 
was chosen to augment the DoD stan¬ 
dards, which were cited to the contractors 
in the Statement of Work (SOW). The 
standards give guidance about defining 
the different development steps, specify¬ 
ing the various pieces of documentation, 
and conducting the major system reviews: 
they therefore are not sufficient by 
themselves to ensure a quality design. 

Scope and purpose of this article. This 
article explains the system architecture and 
design analyses that were specified by the 
FAA for the AAS project, and tells how 
they have been used to provide insight into 
the two competing contractors’ design 
processes. We also provide some lessons 
learned from this project. 

The section on “Primary characteristics 
of an automated ATC system’’ begins this 
explanation by examining basic charac¬ 
teristics of any system for ATC automa¬ 
tion. This description is intentionally 
generic in nature; it is intended to expose 
those aspects of the automation system 
that we perceive to be fundamental archi¬ 
tecture drivers. 

The section on “Design analysis,” 
which is also generic in nature, discusses 
the important issues that a contractor 
must address in order to arrive at an 
acceptable design solution. This section 
summarizes the theoretical foundations of 
the FAA’s contract directives to the prime 
contractors. The FAA deemed it impor¬ 
tant to rethink the traditional approach to 
system design in the context of distributed 


computing systems, but chose not to pro¬ 
vide explicit directives concerning possible 
approaches. 

The “DCP products” section is AAS 
specific. It discusses the contractually re¬ 
quired analyses that have been and will be 
generated during the DCP and shows how 
they document the candidate architec¬ 
tures. The section highlights only the most 
relevant system engineering and system ar¬ 
chitecture studies. 

The final section, which is about “Ar¬ 
chitecture evaluation,” examines the 
FAA’s approach to analyzing the quality 
of the contractors’ architecture submit¬ 
tals. The section includes discussion of the 
verification process carried out by the 
FAA to ensure that the architecture sub¬ 
mittals satisfy requirements. The areas we 
examine are based on aspects of the sec¬ 
tion on “Design analysis” and on the 
primary characteristics of availability and 
evolution, which are discussed in the sec¬ 
tion on “Primary characteristics of an 
automated ATC system.” 

Primary characteristics 
of an automated ATC 
system 

Figure 1 is a top-level, generic view of 
ATC operation. When this operation is 
decomposed into system actions and func¬ 
tions and—at lower levels—these are allo¬ 
cated to humans and machines, certain top- 
level characteristics become noticeable. 

Perhaps the first and most important 
characteristic of an ATC system is the 
availability of system services. This con¬ 
cept of availability includes not only the 
operability of the physical hardware and 
software, but also the continuous supply 
of essential services during foreseen and 
unforeseen problem situations. 

A second characteristic is the evolution 
of system functionality, which must be 
carried out without detrimental impact on 
availability. We discuss this characteristic 
in light of the architectural issues it raises. 

A third characteristic we consider is the 
nature of the data processed, the purpose 
of the data, and the data’s update rate. 

Availability of an ATC system. Because 
of the obvious repercussions of a system 
failure on air traffic safety, extremely high 
reliability and availability of system ser¬ 
vices are required: that is, the availability 
goal for the AAS is essentially 100 percent. 
Providing multiple layers of redundancy 


and fault tolerance protection will mean 
that ATC services to the end users (pilots, 
controllers) are always provided. Current¬ 
ly, the availability of the US automation 
system, taken alone—the system is com¬ 
posed of IBM 9020 computers and the Na¬ 
tional Airspace System (NAS) Stage-A 
software—is not 100 percent. One of the 
major objectives of the AAS is to increase 
reliability and availability to a degree com¬ 
mensurate with the greater dependence 
that will be placed on the automation sys¬ 
tem by controllers. This is especially true 
of the last planned stage of the system 
evolution, at the end of which the control 
instructions generated by the AAS, called 
clearances, will be automatically gener¬ 
ated by the system and transmitted via 
data link to the aircraft. 

For safety reasons, it is imperative that 
the system be available 24 hours a day and 
365 days per year, year after year. Other 
systems can usually be shut down 
periodically. (Mail delivery, for example, 
may be discontinued during the weekends 
and holidays even though large-scale mail 
distribution goes on around the clock.) 
This need for continuous operation char¬ 
acterizes the entire ATC system, not the 
automation-system elements alone. 

Evolution of functionality. By its very 
nature, the ATC system is an evolving sys¬ 
tem. There are many reasons for this. 

First, air traffic will not only increase in 
amount and types of aircraft, but also will 
change in flow; for example, with deregu¬ 
lation and the creation of new airline hubs, 
different markets will increase or decrease. 

Second, the sources of real-time infor¬ 
mation-surveillance radar, meteorologi¬ 
cal radar, and air-to-ground communica¬ 
tions—will continue to improve. 

Third, international regulations in¬ 
fluence US operations. Even if the majori¬ 
ty of the US traffic is domestic, the FAA 
must nevertheless operate in conjunction 
with rules defined by the International 
Civil Aviation Organization (ICAO). 

Fourth, the ATC system has important 
customers, such as the US Air Force and 
Coast Guard, whose needs will evolve. 

Last, the methods of providing control 
will continue to evolve as they have been 
evolving—mainly in the area of the man- 
machine interface. It is important to note 
that neither in the US nor in other coun¬ 
tries advanced in ATC has the evolution of 
these control methods been by giant steps; 
it has always been by small increments. It 
will be the same for the future advanced 
capabilities called Automated En Route 
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Air Traffic Control (AERA). 

The AAS will continuously evolve in the 
future. Continuous evolution has already 
been the case for the present NAS automa¬ 
tion system, and the most visible evidence 
of it will be the transition, in several steps, 
from the present system to the AAS. 
Future changes will occur, and the AAS 
must be capable of accommodating such 
changes—accommodation may, perhaps, 
be achieved by improvements in operation 
functions, modifications in ATC environ¬ 
ment, and insertion of newer, more cost- 
effective technology. These improvements 
must be successfully accomplished with¬ 
out resulting in system downtime or irre¬ 
versible commitment. Further, they must 
not cause performance degradation dur¬ 
ing or after their installation. To meet 
these requirements, the FAA has stipu¬ 
lated other requirements for system modi¬ 
fication and switchover of new or modi¬ 
fied services. 

Main flows of data. The challenge of 
designing the AAS is eased somewhat by 
the characteristics of the main data pro¬ 


cessed by the air traffic being controlled. 
Two data streams important to the AAS 
mission are flight plan data and radar 
(surveillance) data, as shown in Figure 1. 

These two streams do not have the same 
characteristics; The former is created 
once, is updated infrequently, and is dif¬ 
ficult to reconstitute; the latter is created 
almost continuously—that is, it is updated 
at a fast rate, typically every few sec¬ 
onds—and is easy to reconstitute after a 
failure. 

These two sets of data can be used sepa¬ 
rately: their cross correlation, however, is 
what increases controller confidence. 
Knowing what an aircraft (pilot) intends 
to do versus what it (he or she) is doing 
allows the controller to issue effective in¬ 
structions and maintain safety by looking 
ahead 2 to 20 minutes for potential con¬ 
flicts: this is known as the separation 
assurance function. What is true for the 
controllers is also true for the way com¬ 
puters process this information. 

To see how this affects the architecture, 
some comparisons are in order. In the 
past, when computers were relatively new 


and very expensive, it was normal to pro¬ 
cess these data in the same mainframe. 
The spare time available between process¬ 
ing radar reports was used to process flight 
plan information. Magnetic disks were 
connected to the mainframe, but their use 
was primarily for storing the precious 
flight plan data. Today, it is possible, at a 
reasonable cost, to design a partitioned 
system in which different processors han¬ 
dle different data streams and in which all 
data streams can be recorded and 
duplicated for protection. 

Which alternative should be chosen is a 
question decided by other criteria—in the 
example above, cost was obviously a 
critical factor as regards early computer 
technology. For the AAS, the choice is 
simplified because the requirements are 
crystal clear: “The system shall be parti¬ 
tioned to avoid single points of failure and 
to minimize the effects of latent design er¬ 
rors on the functional capability provided 
to the Air Traffic Controllers. ” ^ This par¬ 
titioning also helps the system “to degrade 
gracefully from full performance rather 
than catastrophically”^ and eases the 



viewed as a function that exhibits inputs, outputs, performance indices, and completion criteria. The inputs include the flows of 
flight-plan and radar-surveillance data (which are the most important flows), weather information, flow-management data, system 
status, and aircraft communications (both voice and data link). The outputs include the clearances and advisories issued to pilots 
(with the pilots’ acknowledgments), coordination and control-transfer data exchanged between tbe controllers, and system status. 
Various global parameters describing the environment and the procedures for air traffic control and management constrain opera¬ 
tions. Also, a variety of performance parameters, which include system availability, describe how ATC operation must occur. 
Finally, the ATC system operates continuously for a given aircraft until some completion criterion is specified, such as determina¬ 
tion that the aircraft has left the controlled airspace by landing or by flying beyond controlled airspace. (Separation standards are 
distances to be maintained between aircraft—longitudinally, laterally, and vertically—for a given set of conditions, such as a ter¬ 
minal approach area or a nonradar environment. Separation assurance iook-ahead times are the intervals a controller searches 
ahead in time to detect potential loss of separation standards and thus maintain flight safety.) 
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functional evolution of the system: It 
means that the system can be upgraded or 
replaced in pieces rather than as a whole. 

Thus, the design of an ATC system must 
take advantage of the characteristics of the 
two data streams to address the important 
design trade-offs between availability and 
extensibility. Of course, considering these 
characteristics during the design process 
does not mean that mistakes or poor 
choices will be avoided. It is from this 
freedom to choose that some of the more 
interesting trade-off analyses are born: in 
fact, two of the classic traps that people 
not fully aware of the ATC automation 
world usually fall into are 


• Assuming that radar data is used only 
for tactical control and flight plans only 
for strategic control. This assumption 
typically leads to a system design that calls 
for strict layers of processing. As previous¬ 
ly explained, the characteristics of the two 
types of data and of their processing are 
different, but it is the correlation of these 
two sets of information (plus the sets of in¬ 
formation exchanged with the pilots) that 
helps the controllers to perform their tasks 
at different look-ahead times. 

• Believing that the ATC system is 
naturally a distributed system. Even if 
each team of controllers is responsible for 
a specific volume of airspace, very little in¬ 


formation at the controller (sector) level 
can be processed without interaction with 
the adjacent sectors. At any one time, only 
one sector is responsible for one particular 
aircraft, but other sectors must deal with 
that same aircraft for coordination 
purposes. 

Summary of ATC system charac¬ 
teristics. An automated ATC system must 
be very reliable, be operational 24 hours a 
day, and be capable of being upgraded 
without impeding the control of the air 
traffic. This is in some respects made 
easier because the data processed do not 
have the same characteristics, and there- 
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fore it is possible to design a partitioned 
system. Still, meeting the difficult and 
competing requirements represents a 
serious challenge to the designers of the 
AAS. 


AAS design analysis 

We turn now to consider the range of 
analyses that, the FAA believed, should be 
performed by a contractor in order to en¬ 
sure an adequate system design. The 
philosophy underlying the AAS architec¬ 
ture process is a “clean sheet of paper” ap¬ 
proach. The FAA developed a statement 


of work that described its requirements for 
the conduct of the design process. The 
foundations for this Statement of Work 
were taken from several sources that dealt 
with issues of distributed design.'*’^'® 

The range of distributed design analyses 
falls into four categories of concern: 
global, network (that is, its organization 
and topology), subsystem, and processing 
node', with each is associated a set of ques¬ 
tions or design issues intended to substan¬ 
tiate some particular facet of the system 
architecture. 

Figure 2 provides the framework for the 
set of prime contractor tasks, and is 
presented as a decision tree; key studies re- 


Figure 2. Decision tree for defining 
aspects of AAS architecture. The anaiy- 
sis plan envisioned for the construction 
of the AAS architecture design is a com- 
piex hierarchy of trade studies and deci¬ 
sions that is necessariiy iterative in 
nature; we depict it here by a compressed 
decision tree. The tree is represented as 
four major groups of questions. The 
global area examines the fundamentai 
decomposition of the requirements by 
function and produces the function and 
data partitioning to derive an architec¬ 
ture choice. The network area looks at 
the organizational (topological) arrange¬ 
ment of function allocation onto the 
candidates so as to gain insight into the 
subsystem partitioning and into the pro¬ 
tection concerns being built into the can¬ 
didates. The subsystem area considers 
implementation issues that drive vendor- 
selection activities within a subsystem. 
The processing node area deals with the 
actual software to be built for each node 
in the entire system; it includes the 
details of data access and the problems 
of customizing the operating system and 
executive. Each of the areas is replicated 
for multiple evaluations where required. 
(Key trade-off analyses required in the 
Statement of Work are identified by the 
paragraph number of the requirement.) 

quired by the “Advanced Automation 
System Statement of Work—Design Com¬ 
petition Phase” ^ have the numbers af¬ 
fixed to the paragraphs that mention them 
in the study inserted. It should be pointed 
out that this process is iterative; some later 
design decisions may result from reexami¬ 
nation of early ones. 

Global considerations. The most im¬ 
portant aspect of the architecture design 
process occurs at the beginning; the func¬ 
tional decomposition. This serves as the 
basis for function and data partitioning. 
Function and data partitioning are essen¬ 
tial to the development of a fault-tolerant 
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system as well as for establishing the basis 
for allocating partitioned functions onto 
computers within the AAS architecture. 
Such partitioning also helps the system ar¬ 
chitect to understand the coupling and 
fault-tolerance protection concerns in¬ 
volved for all major system functions and 
data files. (Evaluations of alternative 
design concepts were required of the 
primes so that a baseline system architec¬ 
ture could be established. An essential in¬ 
gredient involves evaluating various possi¬ 
ble allocations of ATC functions in each 
candidate design). 

The expected outcome (with respect to 
fault tolerance) of function decomposi¬ 
tion and partitioning is the establishment 
of a separation of concerns for global er¬ 
ror handling from concerns for each com¬ 
puter subsystem within the AAS. 

The importance of this separation 
aspect of this initial design analysis cannot 
be overstated. For example, the “Ad¬ 
vanced Automation System System Level 
Specification—Design Competition 
Phase” (SLS)2 contains a plethora of re¬ 
quirements that range from the probabili¬ 
ty of detecting potential collisions 20 to 30 
minutes in the future to the end-to-end re¬ 
sponse times for critical processing 
threads, such as processing and display of 
surveillance data. Understanding the com¬ 
plex interrelationships of these require¬ 
ments allows the system architect to derive 
viable function and data partitioning con¬ 
clusions that are traceable (!) and that 
drive the choices of architecture and the 
remainder of the analysis. The FAA feels 
that failure to understand these associa¬ 
tions and partitioning issues leads to an in¬ 
ferior product—and all too often trans¬ 
lates into major technical problems with 
the overall system design. 

Network (organizational) consider¬ 
ations. Following the selection of basic 
system architecture candidates, several 
parallel analyses will be required for con¬ 
solidating and defining the major subsys¬ 
tems and their interconnections. These 
analyses will include consideration of the 
man-machine interface (MMI), the fault- 
tolerant computing strategy, system 
monitoring and configuration control, 
and the local communications network. 
Selections from the parallel analyses will 
lead to secondary analyses. Eventually, the 
results will be combined to specify the 
computer and software components with¬ 
in each subsystem. 

Each function must be examined to 
determine where best to locate certain 


aspects of the MMI. The literature’^ iden¬ 
tifies three levels in the construction of a 
man-machine interface. For any given in¬ 
teraction, such as changing the filed route 
of a flight plan, these levels are known as 

• the semantic (this level tells what in¬ 
puts and outputs mean), 

• the syntactic (this level consists of the 
display and feedback techniques), 
and 

• the lexical (that is, the physical pro¬ 
gram code that implements the tech¬ 
niques). 

The basic allocation choices made possible 
by breaking down the MMI subsystem by 
level are obvious, and they result in vary¬ 
ing benefits derived from off-loading 
computation and from diminution of 
complexity of the function undergoing 
analysis. 

There is a fourth option that must be 
considered, however; an MMI subsystem 
fully allocating the syntactic level and par¬ 
tially allocating the semantic level may also 
be possible, with the most frequently used 
subfunctions being allocated semantically 
to the MMI. This combination is particu¬ 
larly useful for real-time, quick response 
systems. 

For the fault-tolerant computing strat¬ 
egy, there are three basic choices. 

• First, a failsoft approach typically 
called load-shedding may be taken where 
faults cause functionality to be lost. This 
option is classically known by its opera¬ 
tional mechanics: On detection of a fault, 
system operation is reduced to a known, 
safe state (more areas than the faulty one 
may be Inhibited), and functionality is 
rebuilt from this state to the maximum ex¬ 
tent possible. 

• Second, a more active, layered ap¬ 
proach—but a selective one—may be 
taken for those faults that are considered 
more likely or for which some action can 
be taken to eliminate the problem. Layer¬ 
ing achieves isolation of concerns at each 
level, which simplifies error recovery. 

• Last, an aggressive, layered scheme 
may be used to prepare for most, if not all, 
faults that can be foreseen (even very 
unlikely ones). 

Unfortunately, this issue is usually part of 
the last-ditch effort—that is, it is saved un¬ 
til testing detects problems in the design. 

In particular, the system safety reports 
document the results of the contractors’ 
Failure Modes Effects Analysis (FMEA) 
efforts. The analyses of their architectures 
were to address “both potential failures 


that are an inherent consequence of the 
system functional partitioning, and poten¬ 
tial failures resulting from deficiencies in 
automatic fault isolation and recovery 
mechanisms and techniques.”^ This 
analysis describes required detection and 
recovery actions, and it “tests” the ro¬ 
bustness of the system architecture as 
regards faults. 

For highly available systems, the perfor¬ 
mance of system monitoring and configu¬ 
ration control is very important, and is one 
of the key elements to maintaining system 
integrity. The first choice with respect to 
this function is where to put it. Should it be 
allocated to an existing subsystem or a new 
subsystem? Should it be given a dedicated 
and protected independent processor? 
Should it reside in some other function’s 
hot backup? 

Secondary considerations tie into the 
fault-tolerant computing strategy, the 
analyses of subsystems (which take place 
later), and vendor selection. For example, 
it may be deemed desirable in certain fail¬ 
ure modes to migrate functions between 
subsystems. Clearly, this is a config¬ 
uration-control function related to layered 
service-protection schemes; the repercus¬ 
sions of this philosophy may not be appar¬ 
ent, however, until configuration-manage¬ 
ment issues are addressed—for example, 
when one considers heterogeneous proces¬ 
sor architectures. 

The interaction between the fault- 
tolerant computing strategy and the ac¬ 
complishment of system monitoring and 
configuration control is important, relat¬ 
ing as it does to availability, extensibility, 
and evolution concerns, especially where 
these refer to the introduction of software 
modifications under controlled conditions. 
Clearly, addition of software corrections 
and enhancements to an operational sys¬ 
tem cannot be done in an irreversible 
fashion, for if these changes fail, then the 
system is unavailable—not for a small 
number of seconds, but for a large number 
of minutes—while the previous version is 
reloaded. The importance of system moni¬ 
toring is equally obvious here, for without 
complete and consistent monitoring data, 
it may be very difficult to determine the 
causes behind some failure; consequently, 
growth of availability and reliability may 
be impossible (particularly when enhanced 
functionality affects availability growth). 
Since extensibility is a key influence on 
long-lived systems, studies of fault- 
tolerant computing strategies and of sys¬ 
tem monitoring and configuration control 
issues must address it adequately, whether 


38 


COMPUTER 








such studies are undertaken individually 
or jointly. 

Finally, the local communications net¬ 
work (LCN) must be the subject of design 
analyses, which will be carried out in three 
parts to decide the connectivity of the sys¬ 
tem. A technology must be chosen, and 
for each candidate for the technology, 
topologies for connecting the system with 
the subsystem components must be ex¬ 
amined. After a technology and topology 
are available, a media-access strategy must 
be chosen in order to meet response-time 
requirements. In the contemporary mar¬ 
ket, these may be easy decisions, but in¬ 
adequate analysis of the network and of 
the effect of topology on future growth 
may destroy any goals for architecture 
evolution. 

Subsystem considerations. After the 
results from the analyses mentioned above 
are combined and subsystem allocations 
are arrived at, several additional studies 
may be run in parallel. These concern 
redundancy and processing requirements 
by node (per subsystem), as well as trade¬ 
offs in implementing computer software 
configuration items (CSCIs). Selections 
lead to a choice of computer system 
families. 

For subsystem node redundancy, one 
may choose from triple-modular redun¬ 
dancy (TMR—which is to say, the nonstop 
hardware architectures), redundant 
backup (hot, standby, or quiescent), or 
load-balanced redundancy. The differ¬ 
ence between hot, standby, and quiescent 
backup is the delay before the equipment 
is operational. Hot-backup processing 
shadows the operation; standby process¬ 
ing has the operational software loaded, 
but no shadow processing occurs; quies¬ 
cent has at most the operating system and 
executive ready. 

Subsystem node processing is concerned 
with how tightly coupled the processing 
nodes in a subsystem are. Arrangements 
that need to be studied are memory¬ 
sharing architectures, vote-tolerant (that 
is, nonstop) approaches, and hetero¬ 
geneous or homogeneous loosely-coupled 
processors. Each arrangement has an ef¬ 
fect on interprocess communications, 
since tasks executing on heterogeneous 
processor architectures may require data 
reformatting for correct operation (con¬ 
sider the differences between a DEC VAX 
and the Motorola 68000). As noted above, 
subsystem node processing also affects 
configuration management issues: If a 
function resides on one processor but may 


execute redundantly on a second, hetero¬ 
geneous processor, then the config¬ 
uration-management procedures must be 
able to control two separate object files, 
one per architecture type, in all the atten¬ 
dant ramifications. 

As regards the CSCI implementation 
trade-offs, there are a number of different 
programming styles that affect the actual 
cost to develop and test the final CSCI 
package. Programs may be serially reus¬ 
able or be reentrant; they may be either 
parallel or sequential cooperating pro¬ 
cesses; they may do standby management 
or implement N-version redundancy and 
concurrency. Each of these options has its 
own cost in terms of complexity and the 
resultant throughput. For example, it may 
be easier to provide serially reusable func¬ 
tions and to eliminate potential concurren¬ 
cy than to provide parallel cooperating 
processes. 

CSCI implementation trade-offs also 
affect computer-family selection because 
reentrant and parallel schemes require 
support from the hardware and the 
operating system, and not all system- 
family products supply it. Choosing a 
computer family that has hardware sup¬ 
port but does not offer operating system 
support means that said support must be 
added—which effectively creates a new 
CSCI, requires that more code be devel¬ 
oped and tested, and hence increases cost. 
The actual effects of CSCI implementa¬ 
tion trade-offs will be determined in a later 
study, which is described under “Process¬ 
ing node considerations” (below), of the 
operating system and executive. 

Processing node considerations. The 
results of computer selection also lead to a 
set of parallel studies; These analyses com¬ 
plete the design of the system architecture. 
They examine the applications layer, the 
operating system and executive layer, the 
data communications layer, and the data 
access layer (not to be confused with the 
local communications network media- 
access layer). 

For the applications layer, three con¬ 
cerns must be studied: the user worksta¬ 
tion, the dumb-terminal interface, and 
error-handling approaches. 

In an examination similar to the analysis 
of the man-machine interface described 
earlier, the workstation study determines 
just how many of the functions allocated 
to the MMI should be performed within 
the workstation itself, and thereby the ex¬ 
tent the applications program proper is 
unburdened. 


For interaction with dumb terminals, a 
choice must be made among several pro¬ 
cessing alternatives. Should a forms pack¬ 
age be executed on the host or directly on 
the terminal? Should syntactical (that is, 
interaction technique) processing be done 
by the applications? Should both syntac¬ 
tical and lexical processing (the latter is 
physical coding) be done by the applica¬ 
tions? The answers to these questions will 
affect not only the programming burden, 
but also the resource utilization estimates. 

Finally, for error handling we must ad¬ 
dress certain aspects of the data-access 
layer to determine whether data errors are 
best disposed of by recovery-block type 
managers (layers of programming around 
the actual access strategy) or by the ap¬ 
plication itself. Also, function-failure 
disposition must be addressed in light of 
goals for evolution and extensibility that 
were made from previous studies. 

As regards the operating system and 
executive services, various questions must 
be examined to determine if vendor soft¬ 
ware is suitable or if a custom operating 
system or executive must be developed. 
These include questions of error-handling 
options and strategy, of forms of intertask 
(that is, interprocess) communications, 
and of support for dynamic node recon¬ 
figuration. As noted above, results from 
this study eould disqualify a vendor as a 
candidate. 

For the data communications layer, the 
major question is the level of the ISO pro¬ 
tocol that must first be implemented in 
host software. Several vendors have direct 
implementation of level 3 on-board (that 
is, on the bus interface unit), and a few im¬ 
plement level 4. The higher the level on¬ 
board, the lower the overhead incurred by 
the node in accessing the network; such 
overhead, in turn, affects resource utiliza¬ 
tion estimates. 

Finally, the data-access layer defines 
how data will be made available to the ap¬ 
plications. This leads to three basic 
choices. Should access be through a 
vendor-supplied or custom database 
management system (DBMS)? Should ac¬ 
cess be through a program-developed 
data-type manager? Should access be ac¬ 
complished directly by the program? If ac¬ 
cess is to be through data-type managers, 
one is faced with the additional question 
of where the data should be located—in 
memory or in external storage. 

A similar question arises in the case of 
direct program access, where the data 
location may be memory, external storage, 
or external storage with data content pro- 
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tection and validation. These choices af¬ 
fect the inherent stability of the software 
when changes are required in the data in¬ 
terface; they also affect the inherent 
reliability and error containment capabil¬ 
ity should data become corrupt. 

Summary. We have attempted to outline 
the critical issues to be studied during the 
design process. We cannot overemphasize 
the importance to the process of the up¬ 
front effort involved in the functional 
decomposition and partitioning. The 
fault-management issues are equally im¬ 
portant, yet all too often remain ignored 
until late in the design. Clearly, to achieve 
near-unity availability, fault tolerance, 
achieved as a by-product of strict and cor¬ 
rect functional decomposition and system 
partitioning, is essential. 

DCP products 

The AAS contractors’ primary concern 
during the DCP is to develop a new design 
that is suitable for the long life that is pro¬ 
jected for the AAS, that provides a high 
degree of availability, and that can evolve: 
preferably, this development will incor¬ 
porate analysis techniques similar to the 
ideal that is described above. The AAS 
contractors were provided with a high- 
level statement of what the AAS must do: 
the statement covered both function and 
performance. The FAA selected the two 
contractors to compete for the AAS dur¬ 
ing the DCP on the basis of the contrac¬ 
tors’ proposed methodologies for carrying 
out a design effort to meet the AAS re¬ 
quirements. The contractor’s design 
methodology is documented in the System 
Engineering Management Plan (SEMP). 

Besides the general design methodology 
that each contractor proposed for the life 
of the AAS, several trade-off studies were 
explicitly specified by the FAA for inclu¬ 
sion in the SEMP. This was a compromise 
between comprehensive guidance by the 
FAA and total creativity and responsibility 
from the primes, since at the end of DCP 
the primes will each offer proposal bids for 
the AP. 

The FAA analyses are aimed at trigger¬ 
ing the kind of process described in the sec¬ 
tion on “Design analysis” (above). From 
these analyses come various products 
related to design of the AAS. The precise 
and complete content of the DCP re¬ 
quirements is stated in the “Advanced 
Automation System Statement of Work- 
Design Completion Phase” ^ and in the 


“Advanced Automation System Contract 
Data Requirements List—Design Com¬ 
pletion Phase” (CDRL).* 

The most relevant system-design prod¬ 
ucts are detailed in the following sub¬ 
sections. A description is given of each 
product, with emphasis on its availability, 
extensibility, and flexibility. The prime 
contractors are required to find (and hope¬ 
fully the competition is stimulating them 
to find) the most cost-effective solutions 
for the entire AAS life cycle. (In this article 
we focus on the more technical factors, 
since the suggested costs are partially 
driven by the contractors’ marketing 
strategy.) Besides the SEMP itself, then, 
the following five specific analyses were 
germane to the FAA’s evaluation of AAS 
architecture requirements: 

• AAS Architecture Trade-off 
Analysis, 

• Local Communications Network 
Trade-Off Analysis, 

• Advanced Automation Analysis, 

• Computer System Capacity Manage¬ 
ment Plan, and 

• System Performance Model Analysis. 


System Engineering Management Plan. 
The actual process that was chosen by the 
contractor in order to conduct the analyses 
was documented in the contractor’s 
System Engineering Management Plan 
(SEMP). Part of the SEMP must show, at 
least for the selected architecture, how the 
contractor’s use of state-of-the-art sys¬ 
tems engineering and software design 
techniques will help to ensure that the 
AAS can accommodate the functional- 
evolution requirements. In general, these 
techniques will control software devel¬ 
opment in such a way that changes will 
have limited impact, and therefore will 
assist in properly identifying those compo¬ 
nents of the software that are affected by 
change. Structured design and analysis 
techniques will be used to partition the 
AAS software into functionally distinct 
modules. Strict configuration manage¬ 
ment of the software and its documenta¬ 
tion will be used to prevent uncontrolled 
changes. 

The analyses in the SEMP must also 
demonstrate how design techniques that 
separate the logical definition of data rela¬ 
tionships from the physical structure of 
the data will allow addition of new data 
structures to the system. (This separation 
enables the techniques to provide extensi¬ 
bility, usually with little or no effect on ex¬ 
isting functions.) These techniques also 


make the code more robust. Modern pro¬ 
gramming practices, such as the use of 
abstract data types and of data hiding or 
encapsulation, are considered critical in 
the initial development of reliable soft¬ 
ware: similarly, they make it easier to ac¬ 
commodate changes in requirements or 
additional required functions. Separation 
of software functions into discrete process¬ 
es, which are prevented from interfering 
with one another by hardware-enforced 
policies, will also facilitate addition of new 
functions and increase the overall system 
reliability. 

AAS Architecture Trade-Off Analysis. 

Prior to the AAS System Design Review, 
the contractors were required to develop 
and evaluate several candidate system ar¬ 
chitectures. The Candidate AAS Architec¬ 
ture Trade-Off Analysis documents the 
top-level design issues concerning the AAS 
architecture and provides analyses of 
alternative design concepts that are each 
intended to determine the following: 

• allocation of AAS functions: 

• allocation of subsystem modules to 
hardware, software, and operator 
elements; 

• the data-management process; 

• memory, processor, and LCN specifi¬ 
cations, including data rates; 

• an approach to life-cycle manage¬ 
ment: and 

• the necessary expandability of both 
hardware and software architecture 
to accommodate enhancements in 
function. 

The analysis of function allocation and 
subsequent refinements to that analysis 
must consider over 4000 individual re¬ 
quirements for system performance and 
function, as well as their interrelation¬ 
ships. Clearly, a thorough examination of 
these requirements and of their decom¬ 
position is needed to substantiate any 
selected system architecture. This analysis 
will then yield the basis for partitioning the 
requirements between hardware, soft¬ 
ware, and operator elements. Such parti¬ 
tioning must be done in a manner sensitive 
to the critical requirements of highly 
responsive performance, system avail¬ 
ability, and functional evolution. 

Local Communications Network 
Trade-Off Analysis. In order to take ad¬ 
vantage of the fast-evolving communica¬ 
tions technology, the FAA has required 
that the AAS be designed around a local 
communications network that has the req- 
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uisite reliability characteristics and is 
based on local area network technology 
and industry-accepted protocol standards. 
This will permit the introduction of new 
hardware technology and provide for 
function and capacity expansion through 
the addition of computers, controller 
workstations (that is, sector suites), and 
gateways to communication networks ex¬ 
ternal to the AAS—all without major sys¬ 
tem perturbations. 

Design alternatives will be analyzed for 
their support of the total concept of the 
LCN subsystem; the subsystem as envi¬ 
sioned provides for all intrafacility com¬ 
munications (a) among AAS elements and 
(b) between the AAS and other major sys¬ 
tems in the facility. It also provides the in¬ 
terface to other major systems external to 
the facility, as specified in the “AAS 
System Level Specification.”^ In the con¬ 
text of each alternative design considered, 
the following issues will be addressed in 
depth: 

• the ability of the LCN design(s) to 
support the phasing in of other AAS 
elements so as to allow ease of recon¬ 
figuration, smooth growth, and the 
capability for pieces of equipment of 
different design and manufacture to 
communicate: 

• the use of an ISO-standard set of pro¬ 
tocols and, for each layer, designation 
of the status of the protocol (that is, 
draft proposal, draft international 
standard, or international standard); 

• the application and mapping onto the 
contractor’s design of the IEEE 802 
and ISO Open Reference Model in¬ 
dustry standards; 

• the limitations or effects, if any, that 
the LCN design(s) would have upon 
interprocessor dataflow, on response 
times, and on function partitioning in 
the AAS; and 

• network management. 

Key issues to consider in this LCN 
analysis are (a) the effect of proposed 
allocation and partitioning decisions on 
the complexity of the LCN connectivity 
and (b) the physical limitations on 
throughput. 

Advanced Automation Analysis. One 

of the design trade-off studies required by 
the AAS Statement of Work asked that the 
contractors analyze the requirements for 
advanced automation functions, such as 
those embodied in the AERA concept, 
and show how their designs could evolve in 
steps from the initial implementation 
fielded into a system with significantly 


higher levels of controller-task automa¬ 
tion. This study is critical to understanding 
how the contractor views the extensibility 
aspects of his design and how that design 
can be modified as air traffic control func¬ 
tions are shifted from man to machine. 

Computer System Capacity Manage¬ 
ment Plan. A strategy for providing the re¬ 
quired capacity throughout the life of the 
AAS will be developed. This will be an 
evolutionary approach (that is, a phased 
upgrade) that allows adding capacity in¬ 
crementally according to the expected use 
of the AAS. Each contractor’s analysis 
supporting selection of a capacity- 
management strategy for the entire AAS 
life cycle will be based on workload- 
growth profiles, operation scenarios and 
drivers, and workload estimates provided 
by the FAA for functional enhancements. 
At a minimum, the capacity analysis will 
address 

• expansion versus replacement of 
hardware; 

• impact of upgrades on software; 

• impact of upgrades on response time 
and on reliability, maintainability, 
and availability (RMA) performance; 

• cost to the life cycle of alternatives; 

• sensitivity of capacity and perfor¬ 
mance estimates to system workload; 

• forecasts of technology that will 
become available: 

• scheduling interactions for upgrades 
to capacity, for function enhance¬ 
ments, and for insertion of new 
technology: 

• identification of risks in approaches 
to evolution, with means of minimiz¬ 
ing these risks. 

The recommended approach from the 
analysis will be reflected in the contractor’s 
Capacity Management Plan. The plan will 
enable timely and cost-effective prepara¬ 
tion for computer system capacity and ca¬ 
pability over the full life of the AAS. It will 
include (a) a life-cycle plan that will in¬ 
dicate how the AAS will accommodate 
FAA projections of the system workload 
profile over time, (b) the FAA schedule for 
introducing new ATC functions that are to 
be supported by the AAS, and (c) possible 
changes in other workloads. 

From the capacity-management view¬ 
point, the basis for upgrading AAS com¬ 
puter system components is to ensure that 
the response-time requirements for ser¬ 
vices supported by the AAS computer sys¬ 
tem are always satisfied. Some compo¬ 
nents of the initial AAS computer system 


may have sufficient capacity for the entire 
life of the AAS; more likely, however, 
components will be upgraded on a 
schedule in a manner comparable to stan¬ 
dard commercial practice. Since the 
response times for the services will increase 
as the demand on the AAS increases, the 
Computer System Capacity Management 
Plan must be sensitive to these changes in 
demand if it is to enable projection of AAS 
performance into the future so that pro¬ 
cedures for upgrading components can be 
started prior to sustained performance 
degradation. 

System Performance Model Analysis. 
An advanced-automation performance 
model will be developed in accordance 
with the “AAS System Level Specifica¬ 
tion”^ so that the performance analyses 
required can be conducted. These analyses 
will verify that each proposed configura¬ 
tion of the AAS design will meet the per¬ 
formance requirements of the SLS while 
processing the workload expected during 
that configuration’s lifetime. The model 
will also be used to support the analyses of 
the extensibility features of the AAS 
designs as these designs evolve. All expec¬ 
tations that a particular system architec¬ 
ture will behave in a certain way or will 
achieve a certain result will be supported 
by variations that take into account limita¬ 
tions of and contention for resources. The 
models can (and should) be used to sup¬ 
port the decisions of the previous analyses. 

Summary. Collectively, the SEMP and 
the five primary analyses that have been 
described in this section are intended to 
provide a solid technical base for the AAS 
design process; from them, two substan¬ 
tial, fully documented, competitive system 
architectures that comply with the FAA’s 
requirements will be supplied. 

Architecture evaluation 

As the various DCP products (of which 
those listed above are a subset) become 
available, the FAA must verify whether 
the primes’ designs are in compliance not 
only with the “AAS System Level Specifi¬ 
cation,”^ but also with the letter and 
intent of the “Statement of Work.”^ 
Even though architecture decisions made 
during the DCP are the prime contractors’ 
responsibility, the FAA has attached great 
importance to the analyses involved and to 
their influence on the final AAS designs 
that will be proposed by the contractors. 
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Consequently, the FAA has put into place 
several teams of experts from its staff and 
from private industry to perform a critical 
review of these products as soon as pos¬ 
sible from the requirements viewpoint. 
The results of these reviews are provided as 
written comments to the primes. 

In the architecture review process the 
FAA will focus its analyses on a small 
number of specific topics, mainly the ones 
described in the “DCP products” section 
(above) and those required by the SOW. 
During this architecture review process, 
we address the issues of 

• decomposition of functions, 

• availability and capacity, and 

• extensibility and maintainability. 


Decomposition of functions. The pur¬ 
pose of this criterion is to focus on the 
prime contractors’ requirements-alloca- 
tion and function-decomposition deci¬ 
sions in order to ascertain the contractors’ 
understanding of the subtle architecture 
issues that must be identified and raised 
when allocating the various ATC func¬ 
tions to the various architecture alterna¬ 
tives. The allocation and decomposition 
efforts map operation functions and 
dataflows onto candidate architectures. 
Theoretically, this permits the FAA to 
trace a hypothetical aircraft’s flight, as 
represented by radar and flight data, 
through several sectors of airspace—for 
example, departure, en route, and ap¬ 


proach control—to understand how the 
flight’s data would be processed by the 
proposed system architecture. (An exam¬ 
ple of an early version of a top-level 
dataflow and interface diagram based on a 
system-level specification is shown in 
Figure 3.) The criteria used to evaluate the 
function partitioning are 

• Uniform module size. Dispropor¬ 
tionately large modules may adversely af¬ 
fect implementation, testing, and product 
maintainability. 

• A high degree of module cohesive¬ 
ness. To minimize the structural complex¬ 
ity of the software architecture, the func¬ 
tion elements of a module should be 
related to each other and not strongly 



• Proposed departures 
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related to the functions of other modules. 
This module cohesiveness is a good mea¬ 
sure of the maintainability, extensibility, 
and testability of a system. 

• Low module coupling. Low coupling 
(a minimal number and the fewest possible 
kinds of interfaces) between modules in¬ 
dicates a high degree of module indepen¬ 
dence, which permits information hiding 
and thus simplifies the complexity of mak¬ 
ing system modules interrelate. This is a 
measure of maintainability and is related 
to module cohesion. 

It should be pointed out that these tech¬ 
niques evaluate a software architecture 
from a limited and idealistic point of view. 
There may be many good reasons why a 


contractor would choose to override these 
considerations—for example, to meet per¬ 
formance requirements or physical-device 
capacity limitations. Since these design 
characteristics have been proven to in¬ 
dicate potential impacts on performance 
and quality, however, the prime contrac¬ 
tors should acknowledge and offer an ex¬ 
planation of departures from such desir¬ 
able features of good software design. 

Availability and capacity. In this area, 
the FAA objective is to study both the 
primes’ error detection and recovery strat¬ 
egy and the performance requirements 
necessitated by the strategy so it can test 
the sensitivity of each candidate architec¬ 


ture to specific fault events. For certain 
selected configurations, the FAA will also 
want to verify that the prime contractors 
have defined architectures providing an 
inherent hardware reliability equal to or 
exceeding those values specified in the 
AAS SLS. 

The FAA’s view of the analysis of RMA 
and capacity is that it should not be an 
after-the-fact computation or a “guess¬ 
timate” of the selected architecture’s 
availability and capacity. In other words, it 
is not playing with figures related to avail¬ 
ability requirements (0.9999999 for the 
most important functions) or response 
times (0.25 seconds for message process¬ 
ing) under a workload of a “maximum 



[1] Strategic plartning includes conflict prediction, 
resolutions planning, delays prediction, and 
absorption planning. 

[2] The term "clearances" is used in the generic 
sense to include instructions and advisories. 

[3] The man-machine interfaces are not explicitly 


Figure 3. Major ATC functions and interfaces. The 
decomposition-of-function process analyzes a function as 
defined by Alford^ by considering it to be a “black box,” 
then opening it to discover or derive its contents. A generic 
air traffic control system, depicted by Figure 1, can be 
handled in this way, which is the way in which this figure 
was produced; the notation of the figure is that of Gane and 
Sarson.’ Each function (represented by a round-cornered 
square) is a system-level activity that contributes to the 
achievement of the original function’s purpose—to wit, 
“safe, orderly, efficient air traffic control”—consumes the 
same inputs, produces the same outputs, and accomplishes 
the purpose within the same performance constraints. Data 
stores and files (represented by open-ended rectangles) 
define repositories of information necessary for mission 
fulfillment; for example, airspace flow management (in 
other words, strategic planning) is impossible without flight 
trajectory modeling, which in turn leads to the derived re¬ 
quirement that flight plans be saved somewhere. The re¬ 
quirement specification and derived requirements drive the 
decomposition process in an iterative manner. {Association 
checking is the verification that an aircraft is following its 
filed flight plan and is contained within a “bubble” defined 
by appropriate separation standards for its expected posi¬ 
tion. Separation assurance modeling is the analysis of real¬ 
time position reports to determine if ambient condi¬ 
tions—winds aloft, aircraft velocity, etc.—may lead to loss 
of separation in future. These are called alerts and activate 
resolution planning to provide alternative clearances for 
avoiding the problem. Delay prediction analyzes current air 
traffic and weather activities to predict delays because of 
restricted capacity. The results of prediction analysis are us¬ 
ed by absorption planning to determine how the delay can 
be accomplished—at the gate, on the ground, a holding pat¬ 
tern, change of flight pattern, and so on.) 
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site” (140 workstations and 5000 flights 
per center). The RMA studies and the ca¬ 
pacity trade-off studies have been orga¬ 
nized in the SOW to support critical design 
decisionmaking as part of the architecture 
design process. By incorporating the 
models specified in the SOW, the capacity 
analyses are supposed to help in finding 
the most efficient way of satisfying the 
specified response times and of sizing the 
different subsystems. 

The importance of finding the most ef¬ 
ficient way of satisfying the specified 
response times and of sizing the different 
subsystems is even more obvious for RMA 
analysis. As it is written in the SLS, 
“Availability shall be the most important 
consideration in the design of the AAS” ^ 
(italics ours), and in RMA analysis, 
perhaps the single most important issue is 
the error detection and recovery strategy 
chosen by the prime contractor. 

Extensibility and maintainability. The 
intention behind this criterion is not only 


to examine the impact of future en¬ 
hancements on the architecture trade-off 
efforts, but also to study the special 
features provided in an architecture that 
are designed to accommodate the con¬ 
tinuous evolution of the AAS without im¬ 
peding the control of aircraft. Because of 
the importance of system evolution, the 
FAA asked the prime contractors very 
specific questions: Table 1 is a list of some 
of these questions. 

The FAA’s aim is to consider all facets 
of the system architecture to determine 
just how extensible it is. The questions 
asked of the prime contractors included 
queries about hardware aspects (such as 
defining the effort necessary to upgrade a 
central processor or a peripheral for in¬ 
creased capacity or to replace a processor, 
respectively), environmental concerns 
(such as assessing the effects of new sensor 
technology or the use of data link, satellite 
surveillance, or Automated Dependent 
Surveillance Systems), and software issues 
(such as insertion of advanced AERA 


functionality). The questions serve to pro¬ 
vide both a qualitative and quantitative 
assessment of the architecture’s capability 
for evolving to support new functions: 
they also support the availability re¬ 
quirements by promoting isolation of 
areas likely to change over time. 

Summary. The FAA’s evaluation pro¬ 
cess is a difficult task, primarily because of 
the large number of requirements for the 
AAS and the inherent complexity of ATC 
systems. This section has summarized that 
detailed process by examining the three 
areas the FAA views with the most interest 
and concern. 


I n this article, we have reviewed the 
architecture evaluation process that is 
and will be in use by the FAA during 
the DCP. We started this discussion by 
examining generic characteristics of ATC 
systems, proceeded to identify the FAA’s 
expectations of the analysis process by 


Table 1. Sample questions asked regarding the capacity of the AAS architecture to evolve. 

Evolution of functionality is an important characteristic of long-life systems. Recognizing its importance over the known 
evolutionary environment of the AAS, the FAA asked the prime contractors detailed questions to determine the extensibility charac¬ 
teristics of their proposed system architectures. This table lists some of the actual questions given to the prime contractors. 


1. What tools and procedures do you envision being used to design and implement enhancements to the functionality of the 

AAS? 

2. How will alternative approaches to implementing enhancements to functionality be traded off and how will a final approach 
be chosen? Will any metrics be used in this process and, if so, what are these metrics? 

3. What specific features of the hardware and software architecture that you have chosen allow and support enhancements to 
functionality? 

4. What philosophy will you apply to implementation of enhancements to functionality? 

• Minimal disruption to existing modules and databases—in other words, will you keep new functions and databases 
separated from old code and databases? 

• Implementing in such a way as to minimize total software size or total execution time? 

• Some other philosophy? 

5. How do you envision an enhancement to functionality being implemented? Trace the process from conception through 
operational acceptance of an enhancement. 

6. What enhancement(s) to functionality would be most difficult to implement in your chosen hardware and software 
architecture? Why? What is the “weak point” of the architecture? (Note: “Difficulty” and “weak points” might be caused 
by limited hardware resources or specific performance requirements that would be less likely to result in increased 
functionality.) 

7. Describe how data-access software mechanisms will support future functions. Include 

• the impact of a duplicated database on extensibility, 

• the impact future functions would have on data concurrency, 

• the handling of timing problems as regards multiple access paths to data so that response times are not degraded, and 

• the approach taken to ensure effective data-error containment. 
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using a theoretical, ideaiized model, and 
continued with the list of key DCP on- 
paper products that the FAA has used and 
will use in the evaluation. Finally, we con¬ 
sidered the actual review procedures of the 
FAA. 

In general, one can see that designing an 
appropriate computer system architecture 
for a large, distributed system is fraught 
with perils and unknowns. The FAA’s 
methodology and evaluation approach 
have served it well, and therefore we 
recommend their techniques for any large 
automation project. As an example of the 
benefits, part of the review and evaluation 
process, the decomposition of functions 
discussed in the section on “Architecture 
evaiuation” (above), took place between 
the system requirements review (SRR) and 
the system design review (SDR). Even 
without specific design guidance for the 
contractors and with questions related 
only to the requirements, this part of the 
FAA review process has triggered several 
important revisits of the primes’ architec¬ 
tures and improvements to their designs. 
The FAA believes that this review activity 
has been very useful and that it has helped 
the primes to improve their SDR. 

Although we would like to expand our 
conciusions and identify other assets and 
drawbacks of the AAS evaluation method¬ 
ology, we are unable to do so. The DCP is 
still in progress: The data remain propri¬ 
etary and cannot be discussed. A future ar¬ 
ticle targeted to be written in June 1988 
will discuss these in greater depth.□ 
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T he Federal Aviation Administra¬ 
tion has initiated total moderniza¬ 
tion of its air traffic control (ATC) 
automation system. This new system, 
called the advanced automation system, 
has the following characteristics: large size 
(over one million lines of application 
code); real-time, data-processing avail¬ 
ability and reliability requirements that 
approach 1.0; a system life of 20 to 30 
years; changing data sources and function 
over time; and implementation without 
interruption of current ATC service. 
Above all, it is an integral component of a 
total man-machine system, needed to 
perform air traffic control. In recognition 
of this fact, the FAA has made man- 
machine interface concerns an integral 
part of the program, from initial re¬ 
quirements definition, into hardware 
and software design, and through proto¬ 
type test and evaluation, to final system 
implementation. 

One of the objectives of the AAS is to 
provide increased controller productivity 
by installing new workstations, graphic 
displays, and software. This has required 
the Advanced Automation Program Office 
(AAPO) to pioneer, develop, and apply 
methods for engineering the controller 
MMI. The FAA has adopted a method¬ 
ology' that has been carefully integrated 
into the program. It represents a bold step 
toward engineering the MMI with the user 
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as the starting point. In this case the con¬ 
troller is the key not only to the perfor¬ 
mance of the current system, but also to 
the acceptance and use of the AAS end 
product. 

Traditional acquisition approaches 
have resulted in operational systems that 
are cumbersome to use. Often these sys¬ 
tems lack qualities that would permit 
design evolution, user interface language 
extensibility, and accommodation of new 
MMI technology (more powerful displays, 
voice recognition, and so forth). In in¬ 
teractive systems, the MMI includes a 
workstation containing various control 
and display devices that people use in their 
jobs. Other facets of the MMI include 
computer programs that constrain or 
facilitate human-computer interaction, 
the task-allocation and operating pro¬ 
cedures that structure a person’s interac¬ 
tion with a computer, the paper media or 
files sometimes used in conjunction with 
computer processing, and other condi¬ 
tions of the work environment that in¬ 
fluence job performance. 

If the MMI is conceived in these broad 
terms to encompass all factors influencing 
human-computer interaction, then to say 
that “the MMI is critical to successful sys¬ 
tem operations” is to state the obvious. 
Any interactive automated system, 
whether its workstations are used for data 
entry, map digitizing, CAD, flight plan- 
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ning or control, requires effective MMI 
design for effective human performance. 
Analysis of human performance and task 
requirements, equipment selection, work¬ 
station configuration, and MMI software 
and database design must be carefully 
handled. 

This article describes the activities and 
approach that the FAA has adopted to in¬ 
tegrate the MMI into the design process. 
We emphasize the application of the MMI 
design methodology by the FAA prior to 
the design competition phase (DCP) 
award. In particular, we describe the 
critical role of the controller requirements 
validation team and MMI experts. Where 
applicable, sidebars amplify or explain the 
methodology. 

Background 

Within the National Airspace System 
(NAS) the Air Traffic Service promotes 
the safe, orderly, and expeditious flow of 
air traffic. This service is run by a 
professional staff of radar and manual 
controllers. The controller has sole 
responsibility for separating and expe¬ 
diting aircraft within his or her sector of 
airspace. Although the current terminal 
approach control and en-route ATC sys¬ 
tems provide graphic displays of aircraft 
information and printed flight strips, 
currently many of the controller’s tasks 
are manual and contribute to his or her 
stress during heavy traffic conditions. 

The FAA’s NAS plan calls for modern¬ 
ization of the controller’s workstation 
(also termed the sector suite console) and a 
redesign of the MMI software supporting 
controller interaction. This modernization 
will set the stage for introducing more 
powerful, automated functions to further 
enhance safety, controller efficiency, and 
fuel savings for the real user of the ATC 
system, the pilot. This modernization will 
coincide with the consolidation of ATC 
operations at terminal approach control 
and en-route centers into area control 
facilities. 

It is crucial to the success of this pro¬ 
gram that the operational users become in¬ 
volved in the design process from the 
beginning. In this spirit the FAA Air Traf¬ 
fic Service (the user of the system) and the 
AAPO (the engineering organization 
responsible for the advanced automation 
system) established a cooperative mecha¬ 
nism for defining these requirements and 
ensuring their implementation by the AAS 
contractor. The FAA formed the sector 
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MMI design 
methodology overview 

The MMI design process is a method¬ 
ology consisting of six major steps. Each 
of these steps (shown in the accompany¬ 
ing figure, “Overview of the MMI design 
process”) is organized into specific 
designer tasks. This process has been 
documented in a design guidebook, 
which is still undergoing constant revision 
to reflect the application of this 
methodology to various projects. 

Work on this methodology began in 
1978. Since then, significant accomplish¬ 
ments include the development of an MMI 
testbed and dialogue design and proto¬ 
typing language called FLAIR.’^’^® The 
MMI testbed is a powerful tool (being de¬ 
veloped at many companies) that 
specifically supports step 5 of the MMI 
design process. 

Other work is continuing in the devel¬ 
opment of specific design tools that sup¬ 
port the carrying out of each step of the 
methodology. These include use of com¬ 
position graph formalisms, specification 
languages, task description languages, 
and so forth. 

Additional research needs to be done to 
refine techniques for performing step 
6—measure/evaluate human performance 
and ergonomic quality—of the method¬ 
ology. Specifically, metrics for assessing 
ergonomic quality need additional refine¬ 
ment and experimental use. 

Each of the six steps of the MMI design 
process corresponds to a critical phase in 
system development. Also, each step 
results in design information (either de¬ 
cisions, assumptions, or decompositions) 
that logically feeds a subsequent step. 

The accompanying figure, “Overview of 
the MMI design process,” depicts the 
MMI subsystem as it evolves from opera¬ 
tional requirements to operational con¬ 
cepts to design requirements. Operational 
requirements, MMI functions, and 
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automation decisions are derived from a 
decomposition process in step 1. These 
results feed the development of a system 
level specification. Step 2 decomposes 
the human information processing ac¬ 
tivities identified in step 1 and produces 
the concept of operations. This provides 
the foundation for early MMI prototyping 
(step 5) and evaluation to validate the “ops 
concept.” Step 3 uses the operations con¬ 
cept to derive conceptual designs of the 
user interface language and define MMI 
subsystem functional capabilities and per¬ 
formance requirements. These results are 
then used to help define the overall sys¬ 
tem architecture. Step 4 results in seman¬ 
tic and syntactic designs of the user inter¬ 
face. It also formalizes these aforemen¬ 
tioned requirements into functional 
specifications for user interface manage¬ 
ment, applications software, and user 
workstations. Step 5 uses the operations 
concept to develop early hands-on MMI 


suite requirements validation team 
(SSRVT) to identify and validate the sec¬ 
tor suite console and MMI language re¬ 
quirements. 

The MMI design will determine the way 
in which the controller and the machine 
work together to provide safe and efficient 
air traffic control. MMI in this context 
refers to both the sector suite console (con¬ 
sisting of displays and input interaction 
devices) and the computer hardware and 
software that implement the interaction 
language by which the controller and ATC 
automation system communicate. 

The joint efforts of the AAPO and 


SSRVT have already established the re¬ 
quirements of the sector suite console and 
the interaction language. ^ Specifically, the 
equipment for a controller team respon¬ 
sible for a sector will consist of one or 
more sector suite consoles. These consoles 
will be identical, although each may be 
used for a different purpose by the control 
team. The software and hardware that im¬ 
plement the man-machine language will 
permit any console to be used for radar 
control and flight planning functions. 
This will let a controller team continue 
operation without moving to another 
location in case of a console failure and 
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prototypes that serve to validate or 
change key user concepts. Step 5 is also 
performed in support of step 3 to help 
define and/or validate the conceptual 
model of user interaction. Step 6 is done 
iteratively iwith steps 4 and 5 to evaluate 
and enhance the ergonomic quality of the 
system from the user’s standpoint. 

After step 4, it is felt that contemporary 
software engineering and hardware devel¬ 
opment practices effectively translate the 
MMI design into the end-items that make 
up the user interface. 



will allow the rapid reconfiguration of the 
entire control room when required by traf¬ 
fic conditions. 

j Role of the user team 

The most important objective for the 
ATC automation system design is that it 
allow the air traffic controller to do his or 
her job safely and efficiently. To ensure 
that user needs will be met, the controller 
plays a critical role in the entire design and 
development process for the new system. 
The SSRVT consists of five en-route 


controllers, five terminal controllers, two 
air traffic managers, and three regional 
representatives. The AAPO and its support 
contractor. Computer Technology 
Associates, worked with its user team 
counterparts to jointly develop a con¬ 
sistent and complete statement of the 
requirements in a manner suitable to begin 
console and user-interface language 
design. This was achieved through the use 
of a dedicated 10-man multidisciplinary 
team of computer scientists, human 
factors experts, engineers, and ATC 
experts. 

CTA and the SSRVT implemented the 


first three steps of the MMI design process 
methodology. CTA in close cooperation 
with the operational users (SSRVT) jointly 
prepared the operations concept for the 
AAS MMI, ^ the controller man-machine 
functional capabilities and performance 
requirements, and a draft of the sector 
suite console requirements ^ in the form of 
technical reports. Each report resulted 
from our MMI design methodology and 
was reviewed in detail by the SSRVT and 
other FAA organizations. After review 
and incorporation of comments, the con¬ 
troller operational requirements sections 
of these reports were assembled into the 
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AAS specification package.^ 

The AAS system-level specification and 
the three technical reports were provided 
to the design competition phase prime 
contractors. The technical reports were 
included as reference material to provide 
the contextual analysis for how and why 
the MMI requirements in the system-level 
specification were derived. 

During the design competition phase, 
the prime contractors are responsible for 
designing the controller and sector suite 
MMI subsystem and providing prototypes 
of the controller workstation for evalu¬ 
ation by the SSRVT. In addition, they are 
responsible for updating the operations 
concept to reflect their design and further 
refining their user interface design in the 
form of a detailed controller interaction 
and task analysis. The SSRVT will be 
responsible for providing the AAPO with 
their operational assessments of MMI 
designs and evaluation comments on the 
ergonomic quality and operational suit¬ 
ability of designs, mockups, and proto¬ 
types. Using the operations concept and 
MMI requirements databases developed 
prior to contract award, the FAA has a 
program for evaluating the ergonomic 
quality and operational suitability of con¬ 
tractor designs and assessing the effects of 
these designs on controller performance. 


MMI requirements 
definition efforts prior 
to AAS DCP contract 
award 

The objective of the FAA’s require¬ 
ments definition process was to develop a 
complete set of requirements that truly 
reflects the needs of the controller, that 
captures what works well in today’s ATC 
system, and that takes advantage of the 
advances made in MMI technology of the 
past two decades. 

The MMI requirements must be stated 
in terms of function and performance. 
That is, they should state what infor¬ 
mation must be exchanged between the 
computer and the controller to carry out a 
particular task and how quickly this infor¬ 
mation must be exchanged to effectively 
carry out the task. The details of the in¬ 
teraction language (how information is 
entered into the computer and how infor¬ 
mation is displayed) are the responsibility 
of the system designer. To allow the 
designer to optimize the MMI, the re¬ 
quirements must be accompanied by a 


complete description of the human infor¬ 
mation-processing tasks that make up the 
air traffic control job. Any task dependen¬ 
cies and parallelism must be included in 
such a description. 

The FAA’s MMI requirements defi¬ 
nition process entails three basic steps: an 
operational requirements analysis, a 
human performance task requirements 
analysis, and the definition of the MMI 
functional requirements. The first three 
steps described in an MMI design guide¬ 
book ' were adapted and refined by CTA. 
For further details and a summary of the 
steps in the MMI design process, see the 
sidebar entitled “MMI design method¬ 
ology overview” (pp. 48-49). 

The methodology is based on the 
assumption that a system may be decom¬ 
posed into machine functions and human 
information-processing tasks using 
rigorous axiom-based formalisms.® That 
is, a system function or task can be 
categorized as a rule that transforms an in¬ 
put set into an output set. Such a for¬ 
malism enables the designer to represent 
both human and machine attributes of a 
system. The underlying model is a graph 
model of computation that combines the 
following properties: multiple states, con¬ 
trol flow, feedback loops, dataflow, and 
validation points. This model permits the 
representation of concurrency, repliction, 
iteration, sequential dependencies, and 
path selection. Figure 1 provides an end- 
to-end example where the use of composi¬ 
tion graphs captures the sequences of user 
information-processing tasks. It also 
shows the subsequent definition of the in¬ 
terface function requirements. Note how 
the sequence of human information¬ 
processing subtasks in the figure appears 
isomorphic to the functional sequence of 
actions belonging to a workstation and its 
computer. 

We chose the use of composition graphs 
and SREM-like (software requirements 
engineering methodology) formalisms® 
over other methods, like Yourdon’s struc¬ 
tured design,’ Jackson’s design method¬ 
ology,* or the ICAM (integrated 
computer-aided manufacturing) defini¬ 
tion method (IDEF),® because this under¬ 
lying model addresses both the concurrent 
and performance properties of both 
machine and human information process¬ 
ing. It also addresses specification con¬ 
cerns for specification of requirements 
through the design.'® 

In particular, the methods adopted 
address the partitioning and allocation 
concerns involved in separating human 



information-processing activities and 
computer-based processes involved in user 
interaction, display processing, and other 
distributed real-time ATC functions. 
More importantly, this technique enabled 
us to capture the complexity of the con¬ 
troller’s job and identify decision- and 
machine-aiding options to minimize stress 
from task work overload. 

Finally, our objective was to provide a 
decomposition of human tasks such that 
the mapping between computer-based 
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automation processes would be preserved 
and explicitly derived. 

In step 1, operational requirements, 
MMI functions, and automation decisions 
(what functions should be allocated to 
human and which to machine) were de¬ 
rived from a decomposition of operational 
ATC functions. This step was performed 
to document the fundamental trade-offs 
and resulting decisions regarding the level 
of automation services prescribed in the 
AAS system-level specification. In step 2, 


a human-factors task analysis was per¬ 
formed to define the controller’s role 
relative to the advanced automation sys¬ 
tem. This was important in terms of trans¬ 
lating user decisions about prescribed 
levels of automation into descriptions of 
sequences of human information-pro¬ 
cessing tasks. 

The end product of these two steps is the 
formalized concept of operations. It 
describes all controller tasks in terms of 
task composition graphs and a task 


description language. The concept of 
operations contains a description of the 
decomposed sequence of information¬ 
processing tasks in the form of a dialogue 
definition language. Here each task is 
described in terms of the logical displays 
required, the applicable input/output 
interactions, and applicable controller 
actions or decisions. The DDL conveys the 
flow and semantic meaning of each task to 
the designer. 

In the third step of the process, the DDL 
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is translated into functional requirements 
of the MMI. This entails (in sequence): a 
task element analysis that decomposes 
tasks into subtasks: development of a con¬ 
ceptual model of user interaction; devel¬ 
opment of an input/display object proper¬ 
ty list: decomposition of MMI functional 
capabilities: allocation of MMI functions; 
identification of user workstation charac¬ 
teristics; and a failure mode effects 
analysis. The final results are a functional 
MMI specification, including MMI data 
requirements, and the draft sector suite 
console specification. We should point out 


that all requirements, in these last two 
documents are stated in testable terms. 

While the analytical work in this 
methodology was carried out by the multi¬ 
disciplinary team, the SSRVT was an 
integral and active participant in the engi¬ 
neering process. The team provided exten¬ 
sive support in the definition of the ATC 
job, in the allocation of functions to the 
machine, and finally in the validation of 
the requirements. The 15-man SSRVT 
spent a total of 10,0{X) hours on this activ¬ 
ity over an 18-month period. The success 
in the development of the three major doc¬ 


uments and their accuracy in capturing the 
air traffic control job are directly attribut¬ 
able to the complementary activities of the 
engineering and user groups involved. 


AAS operational 
requirements 

Step 1 of the methodology—perform 
operational requirements analysis—re¬ 
sulted in the development of a report en¬ 
titled “Sector Suite Functional Analysis 
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and Trade Studies.” This report provided 
an analysis of ATC operational functions. 
The operational requirements analysis was 
directed toward those functions that will 
become part of the AAS MMI and sector 
suite. As such, this document became the 
conceptual basis for defining the opera¬ 
tions concept for the AAS MMI, and re¬ 
quirements for the sector suite console and 
MMI functions. 

The term “MMI functions” refers to 
capabilities, performance requirements, 
and equipment that (when allocated by the 
designers) ultimately make up the con¬ 



troller/user interface language, display 
management and user applications soft¬ 
ware, and the console/support processing 
elements. 

The exercise of the methodology per¬ 
mitted us to 

(1) rigorously and formally decompose 
ACF operational functions; 

(2) identify automation issues (associ¬ 
ated with each operational function) 
and specify the level of automation 
services to be implemented during 
the initial operational phase of the 
AAS; 

(3) define the fundamental assumptions 
and constraints that became the 
basis for defining and allocating the 
sector suite functional and perfor¬ 
mance requirements; and 

(4) provide a sequence of completeness 
and consistency verifications that 
serve to validate the composition of 
controller information-processing 
activities and sector suite functional 
requirements. 

Figure 2 provides a sequence of decom¬ 
positions that illustrates how the partition¬ 
ing of an operational function produces an 
interface function. This partitioning is 
driven by a trade-off that determines the 
acceptable level of human involvement 
versus machine automation. The SSRVT 
reviewed and evaluated each operational 
function to determine and validate the ap¬ 
propriate level of automation. 

AAS operations concept 
formulation 

Step 2 of the methodology—analyze 
human performance/task require¬ 
ments—resulted in the report entitled 
“Operations Concept for the AAS 
MMI.” This effort can be characterized as 
a human factors task analysis that concep¬ 
tually defines what the human role (in 
terms of tasks) should be in the AAS. See 
the sidebar entitled “The operations con¬ 
cept formulation process”—p. 55—for 
further details on how this document was 
prepared. 

The primary objective of the operations 
concept was to show the decomposition of 
controller tasks to the level of detail such 
that the controller’s job is described in 
terms of 

(1) sequences of tasks that the con¬ 
troller performs when responding to 
a given ATC event; 

(2) a high-level outline of the dialogue 
between the controller and his/her 


workstation; 

(3) interactions with other controllers, 
pilots, and supervisory personnel; 
and 

(4) information needed by the con¬ 
troller to execute tasks accurately 
and in a timely fashion. 

The rigorous documentation of con¬ 
troller information processing tasks, 
dialogue, and task performance criteria 
will ultimately determine the functional, 
physical, and performance characteristics 
of the controller workstation. The goal of 
the operations concept is to enable the sys¬ 
tem designers to understand the con¬ 
troller’s job and to use the task descrip¬ 
tions as a basis for workstation hardware 
and software design. 

In the long term the operations concept 
becomes a tool for the SSRVT to (1) verify 
and validate the quality, accuracy, and, 
completeness of the system designers’ 
technical specifications and (2) under¬ 
stand the impact of proposed changes to 
controller tasks, dialogue definitions, and 
interaction techniques. 

A secondary objective was to charac¬ 
terize controller tasks in terms of 

(1) human capacity and workload; 

(2) machine aids required to maximize 
controller performance; and 

(3) required controller training, experi¬ 
ence, and skill development. 

This secondary objective enables 
human resource management personnel to 
recognize necessary changes in controller 
training and skills acquisition policy. 

It is important to note that the opera¬ 
tions concept is a key element in the AAS 
acquisition strategy. As such it represents 
the operational requirements of the users 
and provides a medium for their involve¬ 
ment in the review of prime-contractor-de¬ 
veloped documentation and sector suite 
prototypes. 

Definition of AAS MMI 
functional and 
performance 
requirements 

Step 3—define MMI subsystem re¬ 
quirements—resulted in the production 
and SSRVT validation of the reports 
“Sector Suite Man-Machine Functional 
Capabilities and Performance Re¬ 
quirements” and “Draft Sector Suite 
Console Requirements Specification.” 
The sidebar entitled “Flow AAS MMI 
subsystem requirements were derived” 
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sector (controller) affected by point-out"... s 



Figure 3. Levels of user language specification. 


(pp. 58-59) provides a road map, used to 
prepare both the MMI functional capabili¬ 
ties and console requirements documents. 

Where step 2 was directed at decompo¬ 
sition of human information-processing 
activities and tasks, step 3 decomposes the 
machine interface functions and defines 
both capabilities and performance re¬ 
quirements. Thus the machine interface 
functions are derived from and supportive 
of the human tasks contained in the opera¬ 
tions concept. This step represents the 
joining or integration of abstract system- 
level functional decomposition and 
human task decomposition. Simply, it 
begins the process of defining what the 
system should look like to the controller. 

This step was tailored to translate the 
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operations concept into derived require¬ 
ments specifications for the AAS MMI 
functions and sector suite workstation. 
The tailoring was done in order to avoid or 
minimize the instances where CTA/SSRVT 
would end up specifying design versus 
requirements. 

One of our key motivations in defining 
user interaction language requirements in 
the “Sector Suite Man-Machine Func¬ 
tional Capabilities and Performance Re¬ 
quirements” document was to introduce 
the paradigm of user interaction language 
design steps identified in Foley and Van 
Dam." These language definition steps 
are described in Figure 3. We adopted this 
paradigm of four basic levels of language 
specification to provide the FAA and 


SSRVT with a road map of design actions 
that translated the tasks identified in the 
operations concept into decisions made by 
the prime contractors about command 
language design, selection of interaction 
techniques and devices, and display syntax 
and associated information coding tech¬ 
niques. 

During the DCP, the FAA has directed 
the prime contractors to document their 
user interaction language design (seman¬ 
tic, syntactic, and lexical levels) in a 
technical report entitled “Controller In¬ 
teraction and Task Analysis.”'^ The 
results of this report are to be incorporated 
into design specifications for user inter¬ 
face and display management software 
and the sector suite workstation. 
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• Defines syntax of input/output * Interaction/display device dependent 

(dispiay format) * Binds hardware capabilities to MMi 

• Defines command ianguage syntax language syntax 

• Defines feedback syntax • For example, bind the touch entry device 

to servo functions of picking commands 



Definition of sector suite 
console requirements 

The concept of the sector suite, or con¬ 
troller workstation, is to provide data entry 
and display capabilities for controllers, 
supervisors, meteorologists, and metering 
and flow control personnel. This includes 
requirements for console hardware and 
related data processing for display and 
auditory device output management, in¬ 
teraction device input management, re¬ 
source management, fault isolation, and 
error detection and recovery. 

These more detailed requirements had 
to be formulated prior to the DCP award 
because of long lead time schedules for 
building sector suite hardware. These con¬ 


straints were a critical element in the AAS 
acquisition strategy and had to be care¬ 
fully planned to coincide with the devel¬ 
opment of new ATC software. 

Figure 4 shows that the requirements for 
the controller workstation were primarily 
derived from a characterization of user 
tasks in terms of display objects, logical 
display types, required semantic and syn¬ 
tactical language response times, machine 
aids, and guidelines for use of coding and 
interaction techniques. A synthesis of 
these task attributes resulted in the devel¬ 
opment of the “Draft Sector Suite Con¬ 
sole Requirements Specification.” This 
document also included assumptions that 

(Continuedonp. 60) 


The operations concept 
formulation process 

The operations concept assumed that 
air traffic controller activities are primarily 
event sensitive. Through the Identification 
and clustering of air traffic events, we 
derived the top-level activity structure for 
the controller. These activities were then 
decomposed according to formal rules of 
decomposition® to arrive at specific event 
stimuli, and the requisite response in the 
form of controiler information-processing 
tasks. Information processing tasks are 
thus initiated by an event stimulus and in¬ 
voke an observable response. Controller 
task performance is influenced by knowl¬ 
edge of ATC procedures, handbooks, and 
so forth. Different types of tasks result in 
behaviors that are either measured by 
human performance indices, such as how 
accurately or in how timeiy a manner a 
controller performs a given task, or sub¬ 
jective estimates of expected behavior. 
The rules of decomposition require that 
each task achieve a closure condition: 
either transition to another task in an 
information-processing sequence, or a 
task closure such as completion of air¬ 
craft maneuver, acceptance of controi, or 
compietion of a message entry (see the 
accompanying figure on pp. 56-57, “Con¬ 
troller information-processing model”). 

Controller tasks define the required se¬ 
quence of interactions between man and 
machine. An example of a task is “Re¬ 
quest Restricted Airspace Probe.” The 
event stimulus (as shown in the accom¬ 
panying figure, on p. 56, “Example of task 
description language”) is a message input 
by visual display or voice. Response to 
this stimulus requires controlier in¬ 
tegration of giobal system parameters 
(such as separation standards, geography, 
route structures current sectorization) and 
controller action (such as initiate flight 
plan conflict probe). This response is 
related to the completion of a task and the 
time and effort (mentai load) required to 
achieve some completion criteria. 

The set of events for the current ATC 
system has been defined and validated by 
the SSRVT® We assumed that the current 
classes of operational ATC events will be 
equally applicable when the new system 
becomes fully operational. In other words, 
the modes of controller-machine interac¬ 
tion will markedly differ in the new sys¬ 
tem, but the event domain will be largely 
the same as in today’s system. These 
events were translated into a set of scenar- 
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ios that describe ATC operations and the 
interactions with the ATC environment. 

The identification and decomposition of 
controller information-processing tasks 
foliow from the scenario development and 
event definitions. The top-level set of con¬ 
troller activities is directed toward meet¬ 
ing the ATC goal of assuring the safe, 
orderiy, and expeditious flow of air traffic 
in today’s system, and remains as the 
raison d’etre of the future ATC system. 

Activities derived from step 1 represent 
the top-level functions performed by the 
controller-machine pair. The term 
controller-machine pair in this context 
denotes the actions a controller performs 
at his or her workstation in response to an 
event or a series of events. The activities 
therefore result from external events, the 
coordination among controllers on a sec¬ 
tor team, or coordination among adjacent 
sectors. 

Task activities decomposed into infor¬ 
mation processing tasks define what 
must be accomplished by the controller. 
Sequences of tasks are documented 
using a task composition graph and task 
description language (TDL).^® (See the ac¬ 
companying figure at lower left, “Ex¬ 
ample of task description language.’’) 
Low-level procedures or precise steps that 
detail how a task is performed on a given 
set of equipment are not presented. 

Rather, the intent is to reflect what is done 
without unnecessarily implying a par¬ 
ticular design (such as object versus 
command-oriented dialogue) or display- 
equipment selection. 

The subsequent analytic steps pre¬ 
sented in the operations concept rely on 
the task decomposition. The level of detail 
represented in the composition graphs 
and TDL allows for characterizations of 
tasks based upon information inputs and 
controller output requirements. Tasks are 
characterized in terms of both ATC com¬ 
plexity factors and sector type (such as 
low altitude arrival, high altitude en route). 
ATC complexity factors include coordina¬ 
tion, traffic density, traffic orientation, traf¬ 
fic separation, sequencing, and time 
responsiveness. 

This initial characterization is used later 
tor operator workload assessments and to 
test the crew/team organization model. 
The cognitive and perceptual attributes of 
a task are used to determine machine 
aiding requirements such as display 
highlighting, special cues, alarms, and so 
forth. Another series of task charac¬ 
terizations provides the basis for deter¬ 
mining controller skill level requirements 
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Definitions: 

Information - A perceptual, cognitive, or motor unit of work which has the 
processing task following properties: 

Event stimulus - Occurrence of an event which can be characterized in terms of 

some message input via a situation display, flight strip, interphone/ 
radio communication or weather report. 

Globai system - Separation standards, procedures, geographic references, and 
parameters other adaptation data. 


performance indices 
Task ciosure 


- Time or accuracy required for task accomplishment. 
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Example of task description language. 
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and developmental training requirements 
per task. 

The culmination of the operations con¬ 
cept is the controller dialogue definition. 
The dialogue between the controller and 
the display console is defined by the 
dialogue definition language. (See the ac¬ 
companying figure on the bottom right, 
“Derivation of dialogue definition lan¬ 
guage.”) The DDL aids in the conceptual¬ 
ization of the model of user interaction, 
display information requirements, and de¬ 
velopment of logical interaction tech¬ 
niques at the task level. Each of the tasks 
was analyzed with respect to the follow¬ 
ing components: 

• Task Type: 

Entry 

Receipt 

Analytical 

Verbal coordination 

• Logical display—aggregates of 
related data objects (such as situation 
display data) documented in the sys¬ 
tem-level specification'^ and needed for 
task performance. 

• Characteristic action type—applica- 
tion-and device-independent methods of 
controller input to the workstation (such 
as select, position, text entry). 

• Display content—information 
directly viewed or manipulated in the 
course of task accomplishment (such 
as runway list). 

By characterizing each task in terms of 
these four components, information 
presentation, information coding, and in¬ 
teraction techniques may be derived in 
step 3 of the methodology. 

The enhanced task statements in the 
DDL impart semantic meaning to the task 
and serve as unequivocal operational re¬ 
quirements statements. 

The documentation of inferences the 
controller would make as a result of task 
performance served both as a validation 
tool for the individual DDL statements and 
as inputs for training-program devel¬ 
opment. 

The construction of the DDL estab¬ 
lishes the link between the event-sensitive 
controller information-processing tasks 
(shown in composition graph and TDL 
form) and the input and display re¬ 
quirements of the controller-system inter¬ 
face. The operations concept, therefore, 
ensures that controller MMI requirements 
are in all cases directly derived from and 
traceable to controller task requirements. 



































































How AAS MMI 
subsystem requirements 
were derived 

As shown in the accompanying figure, 
“Steps in definition of sector-suite MMI 
requirements,” step 1, each DDL state¬ 
ment (derived from the operations con¬ 
cept) was reduced to a series of atomic 
task element statements.''^ Together with 
the anaiysis of controiier input messages 
and dispiayed images, these TESs define 
the required information content of the 
sector suite dispiay. These charac¬ 
terizations are aiso used to derive the ap¬ 
propriate information-presentation coding 
techniques and interaction techniques. 

Each TES is in the form of a singuiar 
sentence structure composed of a verb 
and an object, accompanied by optional 
object modifiers. Objects are defined to 
encompass input messages originating 
from the controller, displayed images out¬ 
put by the sector suite, and conceptual 
“images” that exist in the mind of the 
controller. This syntax follows: 

VERB [OBJECT MODIFIER] 

OBJECT [OBJECT MODIFIER] 

For example: 

SCAN Situation_Display for empha¬ 
sized Flight_Data_Block. 

In the example above, the objects are 
Situation_Display (also termed a logical 

display) and Flight_Data_Block. The 

verb is SCAN. Each TES is uniquely 
categorized as either an act of perception, 
mediation (cognition), interpersonal com¬ 
munication, or user initiation (input). An 
example of the reduction from a DDL 
statement to a series of TES is shown 
below: 

DDL Statement: 

DELETE Flight_Data_Entry and as¬ 
sociated notations from Situation_ 

Display. 

TES: 

DETERMINE need to suppress 
Flight_Data_Entry, 

SELECT Flight_ldentifier, 

EXECUTE Flight_Data_Entry_Sup- 

press_Function, 

DETECT Flight_Data^Entry Sup¬ 
pression. 

Relative frequency, response time, 
priority, type, and quantity of objects dealt 
with are identified for each task element. 
Response times gathered for task 
elements in this step drive the specifica¬ 
tion of performance parameters for the 
functions decomposed in step 3. This in¬ 
formation is also used in step 3 to deter¬ 


mine the overall strategy or conceptual 
model for user interaction. 

In step 2, all of the objects pertaining to 
the controller MMI are identified and 
defined as they surface in the reduction of 
the DDL statements. In step 3, a hierarch¬ 
ical schema or object property list is 
defined such that logical displays are 
defined as the top level constructs that 
specify the outputs to the controller work¬ 
station. A logical display may be reduced 
to a set of composite objects, composite 
objects may be reduced to a set of ob¬ 
jects, and objects may be reduced to sets 
of primitive data elements. 

In the following example. Situ¬ 
ation_Display is the logical display; 

Weather_Descriptor, 

Background_Descriptor, Con- 

flict_Resolution_Options, 
\/\teather_Products, and 
Targetrrrack_Descriptor are composite 
objects. Data_Block is an object, and 

Leader_Line is a primitive data element. 

A structured English format (similar to 
Backus-Naur format) is used to express 
the relationships between object entities. 
Situation_Display = 

{Target/Track_Descriptor] 

and {Weather_Descriptor} 
and {Background_Descriptor} 
and {Conflict_Resolution_Options} 
and {Weather_Products} 

Targetrrrack_Descriptor = 
[Data_Block] 

and [Target_Status] 

and rTrack_Status] 

and [Controlled_Status] 

and [Route_Display] 

and [T''ack_Velocity_Vector] 

Data_Block = 

[Leader_Line] 

and (Full_Data_Block 

or Limited_Data_Block) 

In its ultimate specification form, this 
data represents the definition of inputs, 
display contents, messages, and adapta¬ 
tion data processed by a decomposed 
MMI function. 

The conceptual model of user interac¬ 
tion analysis results in a set of rules, 
guidelines, and heuristics that represent 
decisions about language design, quality, 
extensibility, and robustness. These heu¬ 
ristics are required to ensure consistency 
in the overall MMI design, and to translate 
AAS operational characteristics into a set 
of human engineering dialogue devel¬ 
opment principles. 

In step 3, the conceptual model of user 
interaction is developed by examining the 
nature and frequency of operator actions 



(from step 1) and then integrating human 
factors design principles and guidelines 
with the actions required for the controller 
to achieve his or her goals. The concep¬ 
tual model encompasses strategies for 
both the input of information by the con¬ 
troller and for the output of information to 
the controller. 

Some of the application-oriented fac¬ 
tors that contribute to the selection of an 
interaction strategy include 

• variability from position to position, 
sector to sector, facility to facility; 

• response time requirements; 

• minimization of operator input errors; 
and 

• accommodation of multiple operators 
with varying degrees of experience. 

Some of the human engineering guide¬ 
lines used to select the interaction strate¬ 
gy include 

• continuity within and between tasks; 

• consistent display coding, dialogue 
approach, interaction sequences, 
symbology, and display structure; 

• informative, timely feedback; 

• minimization of keystrokes; and 

• ease of learning. 

The conceptual model can then be vali¬ 
dated during the DCP using the capabil¬ 
ities of the preproduction sector-suite pro¬ 
totypes to simulate interactions vis-a-vis 
the displayed images and dialogue se¬ 
quences called out in the model itself. 
Components of the derived conceptual 
model of interaction become the basis for 
semantic, syntactic, and lexical language 
design during the DCP. 

MMI functional capabilities (in step 4) 
were derived by analyzing and decompos¬ 
ing the input messages, message/display 
output requirements, and expected re¬ 
sponse time requirements specified in the 
previous task element analysis. From 
these inputs, outputs, and response 
times, processing functions and their 
capabilities were defined. For example, it 
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Steps in definition of sector-suite MMI 
requirements. 



was discovered from the task element 
statements that a situation display pro¬ 
cessing function wouid be required to 
support the user activities of air traffic se¬ 
quencing and separation. Thus, it is possi¬ 
ble to preserve the mapping between user 
tasks and required MMI functional capa¬ 
bilities. The conceptual model of interac¬ 
tion was also examined to derive addi¬ 
tional requirements for the user interface 
language components of the functional 
decomposition. 

Requirements were defined for inputs, 
outputs, performance indices, and pro¬ 
cessing capabilities for each decomposed 
function. Note that the methodology re¬ 
quires that inputs must be characterized 
in terms of input interaction techniques, 
input messages entered by the user, and 
display adaptation data. Outputs are char¬ 
acterized in terms of logical display con¬ 


Deflne requirements specification 

tents, display coding techniques, and 
message outputs. These mini-specifica¬ 
tions were subsequently formatted for 
insertion into the AAS System Level 
Specification. 

The allocation step (step 5) involved the 
partitioning and explicit allocation of func¬ 
tions to the elements comprising the MMI 
subsystem. During this partitioning/alloca¬ 
tion process additional layers of functions 
were derived to deal with inter- and intra¬ 
sector suite coordination, system faults, 
and resource management.^® This step in¬ 
cluded a failure-mode effects analysis of 
system and functional components affect¬ 
ing the controller MMI in order to identify 
error detection/recovery actions. This 
preliminary partitioning also resulted in 
the identification of workstation/console 
hardware and user interface software re¬ 
quirements without constraining prime 


contractor design alternatives in any way. 
This step stopped short of what was 
specified in the methodology. The prime 
contractors have been tasked during the 
DCP to formalize their design by showing 
the rationale for their partitioning and 
allocation of requirements to the various 
hardware and software components com¬ 
prising the sector suites. 

The specification of requirements 
associated with the MMI database is ad¬ 
dressed in step 7. These requirements in¬ 
clude the conceptual database organiza¬ 
tion (schema) and the control of integrity, 
privacy, and security of the data. The 
schema identifies the types of data used 
and specifies the relations between 
them. It is the framework into which the 
values of the data items can be fitted. 

The schema, in turn, is derived from and 
dependent upon the user’s view of the 
database (subschema) defined in step 6. 
Data security refers to protection of data 
against accidental or Intentional dis¬ 
closure to unauthorized persons, or 
unauthorized modifications or destruc¬ 
tion. Privacy refers to the rights of in¬ 
dividuals and organizations to determine 
for themselves when, how, and to what 
extent information about them is to be 
accessible to others, irttegrity refers to 
the characteristics and constraints that 
ensure correctness of data. 
















































































of sector-suite con¬ 
sole requirements. 


IlFrom human factors guidelines. | 


The MMI design process 
during the design 
competition phase and 
beyond 


the workstation contained minimally 
essential capabilities, such as input and 
display device management. This alloca¬ 
tion of necessity must not and did not 
preclude prime contractor design alloca¬ 
tion of additional capabilities or functions 
to the sector suites to meet performance 
requirements for availability and response 
time. 

A review of the specifications^ shows 
that the FAA envisions the AAS with com¬ 
puter processing divided between com¬ 
mon processing equipment and the indi¬ 
vidual sector suites. In a typical sector 
suite, multiple displays will provide a plan 
view of the air traffic and weather situ¬ 
ation, alphanumeric flight and weather 
data, and other aeronautical information 
(such as notices to airmen), and traffic 
planning data (including the ability to 
probe the system for conflict-free, fuel- 
efficient flight paths). Sector suite process¬ 
ing and the failsoft and emergency modes 
of the AAS will ensure that the required 
surveillance, flight data, and weather in¬ 
formation are available at each controller 
position as required. 

Sector suites can vary in size from one to 
four common consoles to respond to the 
operational requirements of a given sector 
of airspace. These operational require¬ 
ments vary considerably within an ACF as 
a function of sector size, geometry, and 
traffic, as well as type of ATC position (en- 
route, radar approach control, nonradar 
approach control, or oceanic). This 
freedom of configuration is made possible 
by the modularity and commonality of the 
common console sector suite building 
blocks and their ability to support in-line, 
semicircular, cluster, and other physical 
configurations as required.^ 

Primary components of the common 
console are a main display, a voice switch¬ 
ing and control system (VSCS) panel, an 
optional interactive entry and display 
device, an optional auxiliary display, and 
support electronics. Additionally, each 
console must be capable of accepting a 
keyboard and a cursor positioning/selec¬ 
tion device. 

Increased operational flexibility will be 
achieved because the number of controller 
operating positions can be reconfigured to 
meet changing demand based on day-to- 
day or hour-to-hour workload require¬ 
ments. When traffic decreases, sector 
suites and associated communications can 
be configured into larger geographic sec¬ 
tors, while the total number of operating 
positions and associated staffing will be 
reduced. 


In August 1984 the FAA awarded two 
three-year competitive contracts, each in 
excess of one hundred million dollars, for 
the total AAS design and the development 
of a sector suite console prototype. As 
mentioned before, the design and develop¬ 
ment of the AAS MMI will be an integral 
part of the total AAS design process. 

The FAA’s AAPO and Air Traffic Ser¬ 
vice Requirements and Planning Division 
have been especially farsighted in planning 


for successful acceptance by the users of 
the AAS. Careful attention to detail has 
been paid to ensure that the prime contrac¬ 
tors carry out design tasks in the DCP that 
provide the FAA with the visibility to 
determine ergonomic quality and opera¬ 
tional suitability of the evolving controller 
MMI designs. 

In addition to a series of contractually 
required MMI-related studies (design 
tasks), the prime contractors will be 
responsible for MMI presentations at each 
design review up through critical design 
review. While not required contractually, 
it is anticipated that both contractors will 
use some form of MMI testbed to perform 
design tradeoffs. The console prototype 
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development will include console mock- 
ups, data entry and display service dem¬ 
onstrations, and finally a three-month 
console prototype demonstration. This 
demonstration will take place at about the 
same time as the AAS preliminary design 
review and, therefore, will be based on 
specifically developed demonstration soft¬ 
ware rather than a complete MMI capabil¬ 
ity. The intent of the prototype demon¬ 
stration is to lead to a production decision 
for the console hardware. 

The benefits of user participation dur¬ 
ing the design competition and, later, 
during operational system testing, depend 
to a large extent on the user’s understand¬ 
ing of the requirements and on the conti¬ 


nuity of user involvement. For that reason 
the SSRVT will remain intact until the new 
MMI is ready for implementation. The 
SSRVT will be supported by the mul¬ 
tidisciplinary team to help them under¬ 
stand the contractor-developed technical 
reports and design specifications and to 
support them in the test and demonstra¬ 
tion activities. 

During the design competition phase 
the primary SSRVT responsibilities will be 
to review human factors studies and soft¬ 
ware and sector suite console design 
documents, to review test/demonstration 
plans and procedures, and to evaluate 
mockups, data entry and display devices, 
and console prototypes; They will be con¬ 


cerned with whether or not the specifica¬ 
tion and the user (i.e., operational) re¬ 
quirements are met by these products. The 
SSRVT will also be responsible for assess¬ 
ing the user impact of proposed MMI- 
related specification changes. 

In 1988 one of the two contractors will 
be selected for full production of AAS 
software, hardware, and sector suite con¬ 
soles. Approximately one year after the 
production award, a complete system will 
become available at an FAA test facility 
for extensive MMI refinement and opera¬ 
tional testing. After systems are installed 
at FAA field facilities, it is planned to use 
the systems for a year of additional opera¬ 
tional testing and controller training prior 
to placing the new MMI into operational 
use. These steps, all of which involve ac¬ 
tive user participation, are believed essen¬ 
tial to the continued safety of air traffic 
control during the transition to a new con¬ 
troller workstation and MMI. 

During this acquisition phase, the 
SSRVT will form the core of a larger con¬ 
troller group that will participate in the 
function/algorithm evaluation, MMI lan¬ 
guage refinement, integrated system 
validation, and operational evaluation. 
They will be concerned with whether or 
not the system meets operational needs 
and suits controller transition. 


F or it to be successful, the MMI 
design process must not only start 
in the early stages of system acquisi¬ 
tion, but must be coupled to a plan for 
consistent levels of user involvement 
throughout the life cycle of development. 
Furthermore, in large complex systems an 
interdisciplinary team composed of sys¬ 
tem engineers, cognitive psychologists, 
human factors engineers, display system 
engineers, and software engineers is essen¬ 
tial to the successful application of this 
methodology. Our experience with this 
methodology also bears out that an inter¬ 
disciplinary team, user involvement, and 
commitment to this process mitigate the 
risk of developing unusable MMI prod¬ 
ucts. Work continues and much still needs 
to be accomplished in “packaging” this 
methodology and developing the under¬ 
lying structure of supporting tools, tech¬ 
niques, and guidelines. 

The SSRVT “users” adapted well to 
formal techniques for representing their 
flow of information processing activities. 
They became familiar to the point of 
pointing out problems in consistency and 
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completeness of the task composition 
graphs and task description language 
structured English constructs. Especially 
useful was a glossary of well-defined verbs 
and objects. This enabled both users and 
human factors engineers to apply some 
level of precision to the definition of user 
information processing tasks. This in¬ 
herent taxonomy*® also facilitates for the 
prime contractors the mapping of tasks to 
various interaction techniques and infor¬ 
mation coding techniques employed in the 
design of the sector suite workstation 
hardware and software. 

The translation into engineering 
specifications by step 3 represented from 
the SSRVT viewpoint a departure from 
what they had previously reviewed. 
Though the formalisms were similar (such 
as use of composition graphs and data¬ 
flow diagrams), the rigorousness, com¬ 
pleteness, and volume of technical data as 
much more difficult to digest. The SSRVT 
meetings that focused on the review of this 
document were more formal and required 
walkthroughs by the CTA team. We 
observed that the users (the SSRVT) 
understood the “end-product” re¬ 
quirements if not encumbered with a 
rigorous analysis. However, the audience 
that reviewed the MMI requirements in¬ 
cluded not only the SSRVT, but the FAA 
and other support contractor engineers. 
Here this analysis provided the rationale 
and support for the derivation of MMI 
functions, the user interaction language, 
and console requirements. 

In summary, the challenge to system en¬ 
gineers and designers for this decade and 
into the 1990’s is to bring computer and in¬ 
teractive display capabilities—usefully 
and simply—to people without special 
training (in the case of air traffic control, 
even to the point of making these new 
methods and techniques seem as reliable 
and effective as the old). The eventual goal 
of this methodology is to express the 
knowledge of the behavioral scientist, the 
human factors engineering specialist, and 
the user of interactive systems in a form 
useful to government users, system engi¬ 
neers, and industry developers. □ 
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A team of air traffic 
controllers has 
participated in a 
structured 
requirements 
engineering and 
design evaluation 
process to help 
develop the Advanced 
Automation System 
computer-human 
interface. 


T he development of large complex 
systems involves the derivation of 
requirements from diverse sources. 
In addition to relevant specifications, engi¬ 
neering studies, and technical analyses 
available for existing systems, one of the 
more valuable sources of information for 
the system developer is typically the user 
community. The knowledge gained by 
users on how things “really” work (or fail 
to) sometimes does not fully correlate with 
what is documented in specifications. Often 
times it is just these insights that may form 
the delimiter between success or failure in 
developing advanced systems, both in 
terms of operational suitability and overall 
system performance. The involvement of 
the user community early in the require¬ 
ments definition process facilitates eventual 
user acceptance of the system. 

While the value of accurately capturing 
user knowledge and infusing this knowl¬ 
edge into the system development process 
is clear enough, the process of accomplish¬ 
ing this can be challenging. Users may be 
biased by their own limited experience 
with existing design features, peculiarities 
of their own area of operation (or, as is the 
case with air traffic control, air space 
geometry), or the interaction strategies 
that they employ when using the system. 
Users also tend to offer isolated “fixes” to 
perceived problems, rather than to regard 
functions in the context of system ar¬ 
chitecture or mission performance re¬ 
quirements. Lastly, user terminology 
often differs from engineering terminolo¬ 
gy (e.g., what is the “next available 
sector” in a queueing network?). This 


results in fertile ground for misinterpreta¬ 
tion of requirements by both parties. It is 
for reasons such as these that others have 
previously noted that noncritical accep¬ 
tance of information provided by users 
may constitute the first step on the road to 
design disaster. Of course, failure to ade¬ 
quately tap the users’ knowledge in the 
design process will most assuredly result in 
an operationally unsuitable design. 

This article describes a method used in 
the development of the FAA’s Advanced 
Automation System, or AAS. This meth¬ 
odology is directed toward both the initial 
derivation of requirements and opera¬ 
tional suitability assessments of emerging 
designs. This process does not merely 
“consider” the users (in this case, air traf¬ 
fic controllers), ask them to be passive par¬ 
ticipants, or make attempts at identifying 
requirements that are “likely” to result in 
a “user oriented” design. Instead, the 
FAA and its human factors engineering 
team made a joint commitment to ensure 
the significant and sustained involvement 
of a representative group of actively work¬ 
ing air traffic controllers. This controller 
team, the sector suite requirements valida¬ 
tion team, or SSRVT, is comprised of a 
geographic cross section of air traffic con¬ 
trollers ranging in experience from recent 
journeymen through facility chiefs. The 
charter of the team encompasses deriving 
and documenting computer-human inter¬ 
face, or CHI, requirements for the AAS 
and evaluating the operational suitability 
of designs offered by two competing prime 
contractors—GM-Hughes and IBM. 
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Figure 1. System development cycle vs. human factors methods. 


Human factors in 
system development 

The development of large-scale, com¬ 
plex systems such as the AAS typically 
follows a life cycle demarcated by several 
well-defined milestones. These range from 
requirements definition, through initial in¬ 
tegration testing, to full installation, as is 
depicted in Figure 1. The methods used 
and outputs required of human factors en¬ 
gineering change commensurately with 
these evolutionary states. While funda¬ 
mentally iterative processes, these methods 
usually follow a course of requirements 
definition, design concept development, 
prototyping/testing, and performance 
evaluation. The operational assessment 
role of the user community is also 
modified in this manner as the system 
development proceeds. 

In order to provide continuity and con¬ 
sistency throughout this engineering and 
assessment process, the human factors 
engineering methodology applied to the 
AAS is focused around the development 
of a detailed operations concept for the 


CHI. This document provides an explicit, 
design-independent definition of opera¬ 
tional suitability in terms of controller 
tasks. Because this document is extensive¬ 
ly reviewed and validated by the SSRVT, 
the operations concept formalizes the 
development ground rules for both the 
controller and engineering communities. 
The initial specification of operational and 
CHI requirements for the AAS was driven 
by this type of operations concept work. ^ 
By maintaining the operations concept 
throughout the system development life 
cycle, an objective basis is formed for 
assessments of operational suitability of 
emerging AAS designs. 

Operations concept 
definition 

The operations concept derives air traf¬ 
fic controller activities from a validated set 
of system events. For the purpose of this 
analysis, events are defined in terms of in¬ 
teractions between aircraft, airports, 
airspace, weather, and the ATC environ¬ 


ment (e.g., equipment and subsystems). 
Examples of events include airspace 
release, runway configuration change, or 
sensor failure. The importance of these 
events to CHI design is that their occur¬ 
rence causes the controller to respond 
either by perceiving displayed informa¬ 
tion, entering system messages, or execut¬ 
ing system functions. Through the identi¬ 
fication and logical grouping of air traffic 
events, a corresponding controller activity 
structure can be established that responds 
to these event groups. These activities are 
then analyzed and decomposed to define 
the specific event stimuli, and their cor¬ 
responding requisite responses in the form 
of information processing tasks. The ad¬ 
vantage of deriving tasks from ATC 
events is that the derived task inventory 
will be as complete a characterization of 
the controller’s job as the original event 
list. When performing a task analysis on a 
system that does not yet exist, this provides 
the only valid measure of completeness, 
and is therefore a significant consideration. 

From tasks to specifications. The 
dialogue between the controller and the 
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Figure 2. Task element statements. Task elements are design-independent components of tasks. The verbs (taken from the tax¬ 
onomy developed by Lenorovitz et al.*) show perceptual, cognitive, and user input task components. “Objects” are data items in 
the system with which the user interacts in some way. Element frequency and priority represent the controllers’ qualitative esti¬ 
mate of these parameters with respect to a generic sector under common conditions. These estimates are included to aid in dia¬ 
logue design rather than to drive system capacity requirements, although they can serve as a good qualitative check on system data 
load expectations. The “number of objects” field describes how many instances of a particular data item are typically involved in 
a given action. In designing the sector suite dialogue, the prime contractors must translate task elements such as these into actual 
transactions on the system by making design choices concerning interaction devices, display technology, and screen and dialogue 
design. The design process is then largely one of translating task elements (operational requirements) into controller subtasks (CHI 
design). 


workstation is derived from the task 
analysis by mapping design independent 
display and interaction requirements onto 
the task statements themselves. Tasks are 
defined as entry (of data into the system), 
receipt (e.g., scanning an information 
display), and analytical or verbal coor¬ 
dination (either directly between individ¬ 
uals or indirectly via a communication 
system). Interaction requirements are 
mapped against entry tasks while empha¬ 
sis or alert requirements are itemized along 
with receipt tasks. Qualifiers are also 
added where appropriate to explain why a 
task is performed. 

This information is then embedded in 
the task statement to create an enhanced 
task statement. Enhanced task statements 
are analyzed for data requirements, 
human cognitive and sensory demands, 
and performance requirements. By apply¬ 
ing taxonomic building blocks such as 


those provided by Lenorovitz, Phillips, 
Ardrey, and Kloster® to the enhanced task 
statements, tasks are further decomposed 
into their constituent elements. The 
resulting task element statements are at a 
level of specificity comparable to individ¬ 
ual transactions on the system or com¬ 
ponents of a controller decision task. The 
documentation of this data in the opera¬ 
tions concept, therefore, ensures that 
system level CHI requirements are in all 
cases derivable from and traceable to con¬ 
troller task demands. 

As shown in Figure 2, each task element 
itemizes frequency of occurrence, priori¬ 
ty, data objects, and the number of ob¬ 
jects involved. Embedded within the task 
element verb is the appropriate interaction 
strategy. These task element statements 
represent, in effect, CHI “minispecifica- 
tions.” By mapping this information onto 
an appropriate functional analysis and 


data decomposition (as shown in Figure 
3), CHI system level specifications can be 
derived that have an intrinsically strong 
relationship to the operations concept. 
Task elements also form the detailed basis 
for operational suitability assessment of 
CHI designs. 


Operational suitability 
assessment 

The operations concept can be used to 
derive CHI dialogue and functional re¬ 
quirements. The task analysis data can 
also aid in establishing console ergonomic 
requirements when used in conjunction 
with a comprehensive ergonomic model 
(e.g., Church and Phillips^). Another 
benefit of establishing this information is 
that the operations concept can be used as 
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a baseline to assess the operational 
suitability of emerging designs. 

Systems are typically evaluated with 
respect to compliance to a high-level speci¬ 
fication (termed here the system level 
specification). These specifications 
describe the functional physical and per¬ 
formance requirements that the system 
must meet. In short, the system level 
specification itemizes precisely what the 
system design must do. In order to be ef- 
feetive, requirements included in a system 
level specification must be objectively 
verifiable so that both the FAA and the 
prime contractors can ensure that pro¬ 
posed designs do in fact comply with the 
specifications. 

System architectures are derived from 
sueh specifications. These architectures 
are the result of analyses that drive func¬ 
tional allocations to hardware, software, 
and people. It is important to note that 
functional allocation decisions and sys¬ 
tems architectures, albeit analytically 
driven, often times must be based upon 
design choices. These choices are driven by 
overall design goals (e.g., availability or 
throughput) and by the experience of the 
designer. In other words, an optimal 
design is not solely derivable from even the 
best of system level specifications; the 
design process is rather a synthesis of 
analysis, experience, and creativity. The 
design, then, represents how the system 
will meet the specification. 

The operations concept documents the 
way in which the system will be used 
through the eyes of the controllers and, as 
such, provides insights into why re¬ 
quirements are levied. In effect, this 
specifies precisely what the user expects 
the system to do. The value of the opera¬ 
tions concept to the designer, then, is that 
it provides contextual information not in¬ 
cluded in the system level specification 
that enhances the suitability of design 
choices. By tracing the relationship of 
specific controller tasks (derived from the 
operations concept) to individual require¬ 
ments (derived from the system level 
specification), a metric can be formed to 
describe how completely operational tasks 
are accommodated by design features. 
This is especially important when evalu¬ 
ating the inherently subjective (and 
critical) area of the CHI, where effective¬ 
ness is often confused with beauty in the 
eye of the beholder. 

In the beginning phases of developing a 
design as complex as the AAS, there must 
be a balance of design latitude with design 
guidance. Guidance is necessary because 


financial and schedule constraints render 
the exploration of many novel (and risk¬ 
laden) CHI design approaches impracti¬ 
cal. Engineering resources must rather be 
routed to examine solutions that are both 
feasible and potentially acceptable from 
the user standpoint. On the other hand, 
too much design guidance can stifle the 
design process, resulting in conservatism 
that may circumvent creative and effective 
solutions. 

The establishment of the operations 
concept prior to assessing prototype 
designs provides an effective means for 
building an “assessment ruler” that I have 
found to be successful in yielding appro¬ 
priate guidance, without undo constraint. 
This approach is important when working 
with users who are entrenched in the cur¬ 
rent methods of doing business and who 
possess personal biases about the “right” 
way to design the CHI. These metrics are 
established by examining functional and 
CHI prototype designs both for what they 
must do (derived from the system level 
specification) and why they must do it 
(derived from the operations concept). 

For example, AAS workstations (“sec¬ 
tor suites”) are comprised of one to four 
complete sets of displays, interaction 
devices, and associated cabinetwork called 
“common consoles.” The system specifi¬ 
cation states that cursor control devices on 
common consoles must be able to address 
displays on physically adjacent common 
consoles within a sector suite. The opera¬ 
tions concept goes on to indicate that this 
capability may be used to allow the flight 
data controller to select individual aircraft 
symbols and data blocks (which appear on 
the radar controller’s common console 
display) to assist the radar controller in 
executing transfer of control functions. 
Therefore, in assessing this capability, one 
can test not only if appropriate cursor ad¬ 
dressing is provided, but if it is provided in 
a way that facilitates crew/team perfor¬ 
mance with intersector coordination. 

In this manner, it is possible to assess the 
operational suitability of the cursor access 
scheme and thereby add a dimension of 
design appropriateness to the verification 
and validation process. 

Relevant metrics that may be measured 
in the above example include the effects of 
extreme viewing angles on symbol discrim¬ 
ination and cursor tracking performance 
or ergonomic analyses that focus on lines 
of sight and interaction device accessibility 
with multiple operators. It should be 
noted here that an examination of con¬ 
troller tasks does not in and of itself yield 


the most comprehensive assessment ap¬ 
proach. The contribution of an operations 
concept-based evaluation methodology is 
rather that it provides a realistic and com¬ 
plete set of design goals and operability 
criteria. This approach is more important 
in a very large command and control sys¬ 
tem than, for example, in a text editor be¬ 
cause of the volume, diversity, and criti¬ 
cality of potential transactions that the 
system must support. Given an under¬ 
standing of these criteria, empirical* or 
analytic® methodologies can be applied as 
appropriate to evaluate the performance 
of the CHI design with respect to opera¬ 
tionally valid dependent measures. 

Design competition 
phase CHI suitability 
assessment 

The AAS development strategy has in¬ 
cluded a design competition phase, or 
DCP, in which the competing prime con¬ 
tractors produce sector suite workstation 
prototypes. The assessment of operational 
suitability of these alternative designs dur¬ 
ing the DCP focuses on the interpretation 
of requirements, the appropriateness of 
interaction strategies, display design ap¬ 
proaches, and the physical characteristics 
of the console. Opportunities to measure 
CHI suitability during the DCP take place 
during documentation and design reviews, 
as well as during a series of demonstrations. 

As shown in Figure 4, the assessment 
ruler for these events is built upon a com¬ 
bination of the AAS system level specifica¬ 
tion (Federal Aviation Administration'°) 
and the operations concept. The assess¬ 
ments are designed to work together; i.e., 
the outputs of a given document review 
might impact the assessment profile of a 
following design review or demonstration 
(or vice versa). In all cases, the goal is a 
measure of the degree to which the design 
meets the line items of the specification 
within the confines of the operations con¬ 
cept. This measure of design appropriate¬ 
ness relies heavily on user group (SSRVT) 
validation and is used by the prime con¬ 
tractors to enable timely design modifica¬ 
tion, the FAA to assess progress, and to 
allow the user community to understand 
implications attendant to bringing the new 
system into the field. 

Documentation and design reviews. As 
in any major system procurement, a set of 
engineering analyses and specification 
documentation has been required for the 


66 


COMPUTER 









Figure 3. The CHI specification process. 



Figure 4. DCP Operational suitability assessment process. 
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AAS. In the operational and CHI area, a 
unique and somewhat extensive series of 
such reports was required to facilitate 
SSRVT participation in the AAS CHI 
development. Key documentation in this 
area includes: 

• a revision of the operations concept 
that extends the analysis to design- 
dependent features (e.g., error detec¬ 
tion and recovery): 

• a controller interaction task analysis 
that maps the design-independent 
task element statements to design- 
dependent subtasks. This document 
also traces these controller subtasks to 
line items in the appropriate software 
development specifications, thus en¬ 
suring the link between task elements, 
subtasks, and actual software design; 

• a controller workload modeling 
analysis designed to provide both a 
baseline workload profile and a vehi¬ 
cle for assessing the impact of future 
enhancements to the AAS; 

• a CHI requirements specification 
dedicated to the integration of a 
separately procured communication 
system; and 

• a set of trade-off analyses and 
demonstration documentation that 
focuses on the rationale for and the 
design of the sector suite CHI. 

In addition to these documentation re¬ 
quirements, the DCP has been structured 
around a series of design reviews spanning 
requirements analysis (system require¬ 
ments review) through preliminary and 
critical design reviews. While traditionally 
a “hard” engineering exercise, the AAS 
design reviews have also included a focus 
on user requirements and CHI operational 
suitability at each of these milestones. 

The assessment profile for both docu¬ 
mentation and design review milestones is 
approached in a similar manner. Tradi¬ 
tional compliance verification is achieved 
through specification traceability matri¬ 
ces . An analysis of the traceability between 
system specifications and design docu¬ 
mentation ensures that all requirements 
are supported and also uncovers design 
features not explicitly itemized in the sys¬ 
tem specification. This material is then 
augmented with appropriate operations 
concept data to allow a comparison of de¬ 
sign features with controller tasks and use- 
ability criteria. 

For example, a listing might be com¬ 
piled of all task elements that involve the 
controller performing a “select” type of 
transaction on the system. These task 
elements become the focus for assessing a 


related controller dialogue module de¬ 
scribed in a design review or a specifica¬ 
tion. The task element data would be exam¬ 
ined to analyze task criticality, frequency, 
and other concurrent task requirements. 
The suitability of the dialogue can then be 
assessed based upon a comparison of the 
chosen “select” device (e.g., joystick, 
trackball, touch screen) with transaction 
types, CHI data objects, and the con¬ 
troller tasks the dialogue module is de¬ 
signed to support. By describing the pro¬ 
posed design characteristics at this level of 
detail and presenting them to the user 
validation group, a determination can be 
made as to whether the approach is opera¬ 
tionally acceptable. It should be noted that 
this amounts to a necessary, yet in¬ 
complete, step for design acceptance. 
Human performance measurement and 
dialogue optimization are more precisely 
addressed in demonstrations and tests. 


Demonstrations. A series of demonstra¬ 
tion milestones have been required during 
the DCP that benchmark the sector suite 
design at key points in time. These demon¬ 
strations allow assessment opportunities 
that significantly enhance those conducted 
on the design documentation. Demonstra¬ 
tions have focused on 

• the physical characteristics of the con¬ 
sole design (the mock-up demonstra¬ 
tion); 

• the input and display devices (the data 
entry and display device demonstra¬ 
tion); and 

• the fully integrated computer-human 
interface design (the prototype 
demonstration). 

Controller group participation in these 
demonstrations provides a unique forum 
in which key CHI design aspects can be 
separately addressed, along with the first 
tangible view of the design as a whole. The 
value of these demonstrations is clearly ap¬ 
parent, both from the CHI assessment 
perspective and the potential contribution 
to eventual field acceptance. Because of 
the influential nature of these demonstra¬ 
tions, however, great care must be taken in 
creating a comprehensive assessment pro¬ 
file and in preparing the user review team 
for their participation. A brief, “snap¬ 
shot” view of a CHI design, particularly a 
technically innovative one, can be impres¬ 
sive, even if the design is less than optimal 
for real field operations. Comprehensive 
assessment objectives can significantly 
close the gap between CHI performance in 
factory demonstrations and in the field. 


The mock-up demonstration required 
the prime contractors to fabricate full- 
scale nonfunctioning replicas of their con¬ 
sole designs. In addition to providing a 
host of ergonomic measurements, the dem¬ 
onstrations also included controllers acting 
out a series of miniscenarios, or task action 
sequences, which depicted how the console 
would be used to support air traffic control 
operations. The approach taken for 
operational suitability assessments of the 
mock-up demonstration encompassed 
providing the SSRVT hands-on time, hav¬ 
ing them complete questionnaires, and 
videotaping controller activities during 
task action sequences. 

The controller review team was pre¬ 
pared for the mock-up demonstration 
process by experiencing “dry run” evalua¬ 
tions on a three-dimensional console re¬ 
quirements representation dubbed the 
ergonomic evaluation tool or EET. This 
tool was designed to be faithful to the con¬ 
sole hardware requirements in the system 
specification, yet generic enough to avoid 
representing any particular design ap¬ 
proach. The EET is shown in Figure 5. 

Evaluation instruments (question¬ 
naires, checklists) were initially developed 
through a review of the system specifica¬ 
tion and the operations concept. These in¬ 
struments were then pretested by having 
the controllers exercise task action se¬ 
quences (documented in the operations 
concept) on the EET. The final version of 
the questionnaire included revisions de¬ 
rived from the pretest results. Figure 6 
shows some sample items from this ques¬ 
tionnaire. Note the six-point rating scale 
and the paragraph number references to 
explicit system specification and opera¬ 
tions concept requirements. 

The pretests were videotaped to estab¬ 
lish desired camera angles and to debrief 
controllers following the practice evalua¬ 
tion session. In addition to creating a com¬ 
mon understanding among the controllers 
of the assessment approach and criteria, 
these pretests were designed to reduce any 
possible biases that might arise from the 
initial exposure to one or the other con¬ 
tractor’s design. 

At the prime contractor’s mock-up 
demonstration, the controllers executed 
each of the procedures included in the 
assessment plan. The demonstrations were 
videotaped and were reviewed by the con¬ 
troller team, and the evaluation in¬ 
struments were used to collect the data. 
The resulting data were then analyzed on 
site to provide immediate feedback to the 
controller team. A decision algorithm was 
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Figure 5. Ergonomic evaluation tool. 
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established to convert the continuous data 
(compiled from the six-point scale on the 
questionnaire items) to a dichotomous 
representation that indicated whether or 
not a requirement was considered to have 
been met. This algorithm (equation 1) in¬ 
cluded evaluation rating variance, central 
tendency, and a constant. The constant of 
1.04 was chosen to provide a score that 
would statistically correlate to 85 percent 
of all controllers (assuming a standard 
distribution of responses). Thus this 
algorithm was designed to conservatively 
predict response consistency. Questions 
whose adjusted scores were greater than 3 
were considered to have met requirements, 
while adjusted scores of 3 or less were con¬ 
sidered to reflect operational unsuitability. 

y = ;f-(SD*C) (1) 

where: 

Y = Adjusted score 

X = Mean 

SD = Standard deviation 

C = Constant (1.04) 

The consistency of the questionnaire 
data is reflected by an overall standard 
deviation of approximately 1.04. A post¬ 
test SSRVT caucus was conducted to vali¬ 
date the questionnaire results. In case of 
any rating discrepancies or disagreements, 
the demonstration videotapes were again 
reviewed by the controller team in order to 
arrive at a consensus opinion. Of the 160 
questions (80 per prime contractor), a 
total of 26 items were modified in this 
manner. This final consensus formed the 
basis for the SSRVT mock-up report. 

It is interesting to note that the mean 
standard deviation was significantly 
higher than the overall standard deviation 
for the group of questions where the final 
SSRVT consensus differed from the origi¬ 
nal data (SD = 1.30, t(174)= -2.58,p < 
0.01). Consistent with this is the signifi¬ 
cant correlation between standard devia¬ 
tion per question and shifting of opinion (r 
= .235, p < 0.003). These data reflect the 
considerably higher uncertainty experi¬ 
enced by the controllers with these specific 
items. 

The approach developed for the mock- 
up demonstration design assessments 
allowed those CHI features identified as 
operationally unsuitable to be traced to 
the system specification through con¬ 
troller tasks. This provided the ap¬ 
propriate focus for constructive and time¬ 
ly response by the prime contractors. The 
consensual nature of the assessment also 


served as an indicator of potential future 
acceptance of the AAS CHI design by con¬ 
trollers in the field. Such timely and com¬ 
prehensive feedback facilitated effective 
design redirection and will ultimately 
reduce the need for faulty design retrofits. 

The mock-up demonstration assess¬ 
ments were largely qualitative, and fo¬ 
cused on physical console requirements. 
For the data entry and display device and 
prototype demonstrations, functional 
and performance requirements will be ex¬ 
amined. In each case, the assessment 
ruler will be built upon both the system 
specification and the operations concept. 
The controller team preparation ac¬ 
tivities and consensual validation tech¬ 
niques will also be applied to these other 
demonstrations. 


I n this article I have described the ap¬ 
plication of a methodology that in¬ 
fuses user group knowledge into the 
requirements specification and design 
evaluation process. Key attributes of this 
methodology include the explicit repre¬ 
sentation of user requirements in task 
analysis form, and consensual validation 
of operational suitability. Through appro¬ 
priate execution of this process, the 
controller review teams have been able to 
provide significant design guidance with¬ 
out undo design constraint during AAS 
development. 

The operational suitability assessment 
process, as it is described here, is par¬ 
ticularly well suited for a design competi¬ 
tion environment. Design products are 
assessed with respect to their concordance 
with a comprehensive, user-validated re¬ 
quirements baseline, rather than each 
other. This approach mitigates the natural 
biases that tend to result from direct com¬ 
parisons of differing design concepts. A 
comprehensive assessment profile is 
created that describes, at the controller 
task element level, whether a design has 
satisfied the system specification, and has 
provided a model of interaction that is ap¬ 
propriate for field deployment. Through 
formal channels of feedback to the AAS 
developers, this assessment profile has 
fostered the development of prototype 
designs that are closer to the mark than is 
typically achieved through rote specifica¬ 
tion compliance. 

The controller team design assessments 
will continue to be performed during the 
acquisition phase and on through full 
deployment of the system. The knowledge 


of the SSRVT controllers of operational 
requirements, along with their participa¬ 
tion in AAS design concept development, 
renders them a unique resource for quanti¬ 
fying operational suitability during the 
detailed design and development work of 
system acquisition. The commitment for 
end-to-end controller involvement in the 
specification and assessment process will 
enable the development of an AAS that 
can meet controller expectations and ac¬ 
ceptance upon full deployment.□ 
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Detailed workload 
specification, 
extensive response 
time requirements, 
and precise modeling 
of software behavior 
characterize capacity 
management of these 
complex, embedded 
computer systems. 
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T his article describes capacity 
management of the current 9020 
en-route air traffic control, or 
ATC, computer system, the soon-to-be- 
operational host computer system, or HCS, 
and the future Advanced Automation 
System, or AAS. The goal of capacity 
management is to ensure that performance 
requirements for services supported by the 
ATC computer systems are always satis¬ 
fied. The central capability required to 
satisfy this goal is the prediction of future 
computer system performance. As shown 
in Figure 1, predictions of future perfor¬ 
mance are required for advanced planning 
and decision making. Performance predic¬ 
tions provide data for sizing the computer 
systems at operational sites. Prediction of 
shortfalls in performance well in advance of 
their occurrence allows preventive actions 
to be taken. Advance knowledge can pre¬ 
vent the degradation of performance or the 
necessity of limiting system functionality to 
alleviate capacity overload conditions. 

0018-9162/87/0200.0073$01.00 © 1987 IEEE 


Figure 1 illustrates how the predictive 
function is dependent upon data from 
other capacity management elements. Ac¬ 
curacy of this supporting data is critical to 
the accuracy of the predictive performance 
models. Definitions of the expected future 
workload and future functional enhance¬ 
ments are used by the model to predict 
future computer system performance. 
Measured values of current workload and 
performance parameters are used to 
validate performance models and verify the 
proper current performance of the systems. 
Operationally, measured data are used to 
validate assumptions made in the model. 

Shortfalls in capacity have occurred in 
the current 9020 systems. In part these 
shortfalls were caused by the lack of a 
reliable performance prediction capability. 
A major challenge in capacity management 
for the new HCS was to develop a tool for 
ongoing prediction of performance—a per¬ 
formance model to provide regular, timely, 
and accurate predictions of performance 
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Figure 1. Interrelationship of capacity management activities. 


for all HCS installations. This article 
describes development of the HCS perfor¬ 
mance model as a component of the HCS 
capacity management system. The develop¬ 
ment of related capacity management ele¬ 
ments is also described. Each element of 
capacity management is discussed in terms 
of its evolution from the 9020 system 
through the AAS. The approach for the 
9020 system, recent accomplishments in the 
HCS, and planned capabilities of the AAS 
are described. (The competitive nature of 
the AAS procurement limits the description 
of specific AAS approaches.) The objective 
of the article is to provide insight into the 
process of capacity management for a com¬ 
plex, mission-critical computer system, the 
problems encountered, and approaches 
that have been found to be valuable. 

Performance 

requirements 

Performance requirements provide the 
criteria for capacity management decisions. 
Deviations of current or projected com¬ 
puter system performance from required 
performance levels are determined using 


measurements and/or performance mod¬ 
els. Required performance is quantified in a 
manner that permits direct comparison 
with measured or modeled data. In addi¬ 
tion, performance requirements are directly 
relatable to end user needs. 

Performance requirements for ATC 
computer systems are specified in terms of 
response times for the automation services 
provided. Hundreds of types of computer 
actions are associated with critical auto¬ 
mated ATC functions. The responsiveness 
of each action is important to overall mis¬ 
sion success. In order to provide a man¬ 
ageable number of meaningful system per¬ 
formance measures, the complete set of 
individual computer actions has been di¬ 
vided into a small number of classes. Each 
class consists of those actions having similar 
responsiveness requirements. Responsive¬ 
ness requirements are placed on the ag¬ 
gregate actions in the class, weighted by 
their frequency of occurrence. Thus, the 
number of ATC system performance met¬ 
rics varies as the number of classes, not as 
the number of individual computer actions. 
In the largest case, the number of response 
time classes is 13. 


Response time requirements for the ex¬ 
isting 9020 computer systems have two im¬ 
portant characteristics: 

(1) they apply only to simulated test en¬ 
vironments and 

(2) they refer only to the response time of 
the 9020 mainframe. 

The first of these characteristics implies that 
the requirements for the 9020 system are ac¬ 
tually benchmark requirements. Accept¬ 
able performance is determined from spe¬ 
cific benchmark tests. Actual performance 
in an operational environment is not part of 
the response time criteria. In practice, the 
criteria are used to determine the relative 
performance between the present configu¬ 
rations and new software releases or hard¬ 
ware upgrades. If the performance is 
similar for the benchmark test, then similar 
performance is inferred for operational 
conditions. However, absolute response 
time performance under operational condi¬ 
tions is not determinable from the bench¬ 
marks. (In fact, the simulated test condi¬ 
tions of the 9020 system typically induce 
approximately 75 percent of the computa¬ 
tional load of the actual operational condi¬ 
tions.) There are no requirements for op¬ 
erational response times of today’s 9020 
systems. 

The second characteristic of response 
time requirements for the 9020 systems 
limits the application of the requirements to 
the mainframe subsystem, thus neglecting 
delays caused by the display subsystem as 
shown in Figure 2. The display subsystem 
can create delays that significantly affect 
controller-perceived end-to-end response 
times. One of the anomalies of the 9020 
system has been that response time mea¬ 
surement tools (discussed later) include 
these delays, making the measurements in¬ 
compatible with the requirements. 

Response times for the HCS have been 
specified for a more realistic test environ¬ 
ment than the 9020 system. The objective is 
to test the HCS responsiveness in a way that 
response times in operational conditions 
can be inferred from the simulated tests. 
Improved simulated load tapes were devel¬ 
oped that provide a load that is much more 
representative of actual operational condi¬ 
tions. Response time requirements are ex¬ 
pressed in terms of performance against 
these improved simulated test loads. To 
further improve the HCS response time 
definition, the HCS response time bench¬ 
mark requirements are spiecified to apply 
when all auxiliary functions are active. 
Auxiliary functions include p)erformance 
monitoring and data collection. A short¬ 
coming of the 9020 system is an inability to 


74 


COMPUTER 


































































record such data as response time perfor¬ 
mance when the system is heavily loaded. 
By specifying response times to apply in a 
fully loaded functional condition, these 
problems will be avoided in the HCS. 

Building on experiences with the 9020 
and the HCS, a new approach was taken 
for the AAS. First, response times re¬ 
quirements don’t end with the satisfaction 
of benchmark tests, but apply to all opera¬ 
tional conditions. This was accomplished 
by the detailed specification of the opera¬ 
tional conditions, i.e., the operational 
workload. Secondly, the AAS response 
time definition extends previous definitions 
by defining response times in terms of the 
times between the initial request and the 
final response to the controller. While 9020 
and HCS times apply only to the central 
computer system, AAS times are end-to- 
end response times. 

ATC computer systems typically provide 
several different responses to each re¬ 
quested action. Consequently, several 
response times are specified for each action. 
The “lexical” response time is the time to 
provide immediate feedback to operator 
entries such as keystrokes. “Syntactic” 
response time is the time until acknowl¬ 
edgement of the syntactical correctness of 
the operator entry. “Semantic” response 
time is the time until the results are 
displayed at the appropriate destination. 
For the AAS each response time is assigned 
to a class for the purpose of responsiveness 
definition. Also several statistics are used in 
the response time requirements. Both the 
mean value and a percentile value are used. 
Table 1 shows some sample values for the 
AAS. 



Figure 2. Response time 
definitions. 


Table 1. AAS response time requirements. 


Message 

Mean (s) 

99th percentile (s) 

Lexical feedback 

0.05 

0.1 

Syntactic feedback 

0.25 

0.5 

Flight data changes 

Output to entering position 

0.6 

1.2 

Output to remote positions 

1.5 

3.0 

Trial flight plan 

Output to entering position 

1.5 

3.0 

Meteorological data changes 

Output to entering position 

2.0 

4.0 

Output to remote positions 

3.0 

5.0 


Workload 

Development of workload requirements 
is central to the success of the planning 
aspects of the capacity management pro¬ 
cess. Although each of the 20 en-route air 
traffic control automation systems in the 
United States is functionally identical, 
workload requirements vary widely. Varia¬ 
tions from facility to facility are a function 
of the density of commercial, military, and 
general aviation traffic, as well as environ¬ 
mental characteristics such as numbers and 
types of surveillance sensors, airports, and 
other aviation facilities that communicate 
with the en-route sites. 

Workload specification. Workload spe¬ 
cification for capacity management serves 
three different purposes. First, the work¬ 


load specification defines the design limits 
and maximum stress workload that the 
automation systems are to meet. Second, 
the workload definition is used as an input 
to system performance models to provide 
predictions of future system capacity re¬ 
quirements. Finally, the workload defini¬ 
tion provides the details needed to build a 
capacity and response time test to be used 
during system testing. 

Computer system workloads are speci¬ 
fied in terms of natural forecasting units, or 
NFUs, rather than in terms of internal sys¬ 
tem transaction rates. This choice occurs 
quite naturally, primarily because of the 
functional nature of the system specifica¬ 
tions and because a majority of the system 
functions either represent automated oper¬ 
ations on flight data objects, implement 
interfaces to some aspect of the ATC envi¬ 
ronment, or support a controller need. Air 


traffic controllers, for example, can esti¬ 
mate how frequently an automation func¬ 
tion can be used for each flight that is con¬ 
trolled: they would not, on the other hand, 
be able to estimate the overall system trans¬ 
action rate for that function. 

Workload definition is accomplished 
through the use of workload parameters. 
These parameters describe either a charac¬ 
teristic of the ATC environment or a con¬ 
troller’s response to that environment. For 
example, such workload parameters as the 
number of aircraft tracks, the amount and 
type of radar coverage, and aircraft radar 
beacon transponder equipage define the 
ATC environment itself. Parameters such 
as the number of flight plan amendments 
per flight and the number of various con¬ 
troller input requests per flight define the 
controller’s response to the environment. 
Other parameters, such as the speed distri- 


February 1987 


75 




























bution of flights and their type distribution 
(arrival, departure, etc.) provide details for 
building capacity and response time tests 
but have only marginal effects on the sys¬ 
tem workload. 

The workload parameter selection pro¬ 
cess is subjective. It started by developing a 
list of possible parameters, beginning with 
the FAA’s workload parameters that de¬ 
fined the 9020 requirements. Other possible 
parameters were identified through a sur¬ 
vey of performance models for the 9020, 
design documents, and performance mod¬ 
els and testbed activities for more advanced 
automation functions that will be imple¬ 
mented in the host and AAS. This list was 
then examined and reduced to the mini¬ 
mum number necessary to account for the 
majority of the system load and to provide 
the details necessary to build a capacity and 
response time test. 

Development of the new HCS workload 
was based on measurements on 9020 system 
workload. ATC applications software exe¬ 
cuting in the HCS in the future will consist 
of the 9020 system software in the field to¬ 
day and several new functions. As a result, 
the current workload on the 9020 systems 
across the United States provided a good 
baseline from which the future workload 
requirements were predicted. This was the 
core of the workload definition effort for 
the HCS. 

The 9020 site data were reduced and 
analyzed by a set of software tools that 
determined the values of the HCS work¬ 
load parameters at each site based on the 
sample data. A composite “maximum 
stress” HCS load was then built from these 
site samples. The parameter values for the 
maximum stress loading were then forecast 
through the expected lifetime of the HCS 
based on FAA traffic forecasts and the 
FAA’s implementation plans for func¬ 
tional enhancements. 

The subsequent development of AAS 
workloads was considerably more difficult 
than HCS workloads. First, the AAS work¬ 
load requirements had to be stated in a 
form that was “architecture independent”; 
in the competitive design environment of 
the AAS the workload requirements could 
not be stated so as to bias architecture deci¬ 
sions. Second, the AAS systems will be sup¬ 
porting area control facilities, or ACFs— 
consolidated facilities that provide both en- 
route services and approach control ser¬ 
vices. ACF boundaries and missions are 
very different from those of current day 
facilities, making extrapolation from the 
current operation difficult. Third, the 
system is to interface to new surveillance 


sensors, new ground-based systems for 
weather and flight services, and will include 
automation capabilities that have not 
reached a state of development from which 
measurements can be made. 

The workload development process 
starts with the development of a parameter 
set in the same manner as that for the HCS. 
Parameters are assigned values in a multi- 
step process. First, values are determined 
for the parameters based on observed loads 
for the current 9020 sites. If the existing 
data are not available, estimates of the 1985 
load are made based on engineering anal¬ 
yses of design data for the hardware or soft¬ 
ware systems that will be either generating 
the load (in the case of radar sensors) or 
processing the load (in the case of advanced 
automation functions). These 1985 loads 
are then forecast to the future using FAA 
traffic forecasts based on existing facility 
definitions. Finally, the forecasted loads for 
today’s facilities are then allocated to the 
proposed ACFs based on current plans that 
include the proposed ACF boundaries and 
schedules for consolidating approach con¬ 
trol services into the ACFs. This process is 
illustrated in Figure 3. 

Capacity and response time testing. 
Capacity and response time testing using 
fixed benchmarks has been used extensively 
by the FAA. The tests simulate the external 
workload environment of the ATC com¬ 
puter systems. Capacity and response time 
tests were an important part of the 9020 
system acceptance in the 1970’s, and have 
been part of the regression (i.e., com¬ 
parison) testing for new versions of the en- 
route automation software to establish the 
capacity impact of the release. Capacity 
and response time tests are an important 
part of the HCS requirements verification, 
and are anticipated to play an important 
role in AAS acceptance testing. 

The 9020 capacity and response time tests 
were developed in the early 1970’s based on 
the then current ATC conditions, and 
tested only the basic functions in the 
automation system at that time. As the en- 
route system matured and new functions 
were added, the complexity of the older 
tests discouraged modifications to ade¬ 
quately exercise the new functions. Since 
the test design did not take into account the 
radar separation standards, for example, 
the conflict alert function that warns con¬ 
trollers when flights under their control are 
about to violate aircraft-to-aircraft separa¬ 
tion standards generates far too many alerts 
for the older tests to be a useful indicator of 
system capacity. Moreover, the older tests 


were limited to only a maximum 444 instan¬ 
taneous flight sets and underestimated the 
actual field loads by 25 percent. 

Since the older tests are used as a regres¬ 
sion test for new versions of the 9020 soft¬ 
ware, their shortcomings were not a signifi¬ 
cant problem when applied to the 9020 
system. However, the shortcomings in the 
older tests could no longer be ignored for 
HCS capacity testing. The differences be¬ 
tween the 444-flight set and the forecasted 
600-flight workload were significant. In ad¬ 
dition, the laek of systematic testing of 
newer automation functions and lack of 
flexibility to modify the test for future 
automation functions were seen as serious 
limitations on the utility of the test. As a 
result, a new test, using a new host load 
tape, or HLT, was designed and built for 
host capacity and response time testing. 
The HLT contains a component scenario of 
only 39 flight sets, versus 112 for the older 
tests, greatly simplifying the complexity of 
the tape. The scenario was designed to 
generate the mixture of loads (e.g., con¬ 
troller input and radar target messages per 
flight) described by the host workload re¬ 
quirements, and to properly load the new 
and proposed automation functions for the 
HCS. 

Automation was used extensively in the 
construction of the HLT. Although the 
routes for the individual flights had to be 
developed manually in a way that meets the 
corresponding workload parameters, auto¬ 
mation was used to insert messages that are 
nominally entered when flights depart, ar¬ 
rive, move from one control jurisdiction to 
another, or are acquired by or dropped 
from radar contact. Information display 
messages, which do not influence the con¬ 
trol status of the flight, are randomly added 
to the scripts according to their expected 
frequency. 

The end result of this initial manual input 
and automation support is a set of basic 
flight scripts that describe the flight and all 
input messages that will be entered on its 
behalf. Each of these basic flight scripts is 
then systematically repeated to attain a de¬ 
sired instantaneous load of 200, 400, and 
600 flight sets. The process is also auto¬ 
mated, repeating flights and all their related 
input messages at specific intervals that are 
defined so that the workload definition 
goals are met and proper spacing of flights 
along their routes is maintained. 

Validation was an important aspect of, 
the HLT development project. A reduced 
load version of the HLT was run on a 9020 
configuration to ensure that the test 
operated correctly. During these tests, the 
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Figure 3. Workload data sources and products. 


en-route automation software recorded the 
test conditions in the same manner that the 
9020 sites recorded measurement data dur¬ 
ing site sampling for the workload defini¬ 
tion activities. These recordings were then 
reduced and analyzed by the same software 
tools that determined workload values on 
the site data to guarantee that the workload 
contained on the HLT matched the site 
workloads when measured by the same 
software tools. 

The end results were very satisfying. The 
workload on the HLT compared within the 
10 percent limit established in the test 
definition goals for the most critical 
parameters, and for most of the remaining 
parameters. Development of simulated 
loads to exactly match workload specifica¬ 
tions would be very difficult and not cost ef¬ 
fective considering the uncertainty in the 
workload specification. When field data at 
similar workload and operational condi¬ 
tions were compared with the host load 
tapes, the load tapes overstated the mean 
field processor utilization by only 7 percent, 
and was within 1 percent of several sites. 


Functional enhancements. For evolu¬ 
tionary systems such as the US ATC com¬ 
puter systems, definition of future func¬ 
tional enhancements planned during the life 
of the systems is a very important compo¬ 
nent of capacity management. Functional 
enhancements for the air traffic control 
system exist in various stages of develop¬ 
ment—from concept definition, to detailed 
design level specifications, to development 
testing and evaluation, or DT&E. The 
workload definition effort also includes the 
development of inputs to performance 
models that describe the planned functional 
enhancements to the automation systems. 

As many as 11 functional enhancements 
are planned for the HCS during its lifetime. 
In order to predict the capacity and 
response of the HCS after the implementa¬ 
tion of these enhancements, inputs for the 
host performance models that described 
these enhancements were required. These 
inputs included the identification of the 
software tasks, called program elements or 
PEs, which implement the function, the 
connectivity of these PEs with other PEs, 


the priority and frequency of execution of 
the PEs, and the PE internal logic and in¬ 
struction counts. 

For the functions that have reached 
DT&E, the PE identification, PE connec¬ 
tivity, PE priority, and PE internal logic 
and instruction counts could be determined 
by studying the code that implemented the 
functions. For other functions, the process 
was more difficult. The most recent design 
descriptions, functional requirements, or 
other supporting documents that provided 
the latest description of the function were 
located and studied. If no implementation 
had been developed, an implementation 
that postulated PE identifications, priori¬ 
ties, and internal logic was developed. The 
logic was then sized by a group of four soft¬ 
ware engineers; the high and low estimates 
were discarded, and the average of the two 
midrange estimates was used. 

AAS enhancements. A major goal of the 
AAS is to provide an architecture that can 
be easily extended to support additional 
workload and functional enhancements. 
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The introduction of future automation 
functionality, for example, is planned as an 
evolutionary process. ATC problem pre¬ 
diction functions, such as flight plan con¬ 
flict probes, will be introduced with the ini¬ 
tial implementation of the AAS. Higher 
levels of automation, such as the introduc¬ 
tion of automated problem resolution plan¬ 
ners, will follow. Other functional enhance¬ 
ments, such as clearance delivery support 
for an air-ground data link, the automated 
delivery of flight clearances to aircraft, or 
satellite-based surveillance may also be re¬ 
quired in the future. 

These enhancements will be sized in 
much the same manner as the HCS en¬ 
hancements; implementation schedules and 
sizing estimates will be provided to the AAS 
contractors, who will then incorporate this 
planning data into their AAS system per¬ 
formance models and obtain predictions of 
hardware requirements necessary to sup¬ 
port the enhancements. This process will 
provide the lead time to procure hardware 
having sufficient capacity to support the 
enhancements by the time the enhance¬ 
ments are ready for field testing. 


Measurement 

Measurement of workload and perfor¬ 
mance is an important aspect of capacity 
management for ATC computer systems. 
Measured values are used to compare ac¬ 
tual performance and workload with pre¬ 
dicted values, to validate performance 
models, and to serve as a basis for projec¬ 
tion of future performance. Measurement 
capabilities in the ATC computer systems 
have evolved to support the capacity man¬ 
agement process, building on past ex¬ 
periences. 

9020 and HCS measurement capabilities. 
Measurement capabilities in the existing 
9020 system and the HCS are very similar 
because of the commonality of software be¬ 
tween the two systems. The 9020/HCS per¬ 
formance measurement capabilities include 
on-line recording tools and off-line data 
reduction and analysis tools. The system 
analysis recording, or SAR, tape provides a 
data source for system analysis and evalua¬ 
tion. The data that is recorded on the SAR 
tape reflects the data entered and displayed 
to control personnel, data processed inter¬ 
nally by programs, and such system events 
as PE dispatching, external and internal in¬ 
terrupts, and I/O operations. 

Response times are measured by reduc¬ 
tion of the SAR tapes since all system inputs 


and outputs are recorded on these tapes. 
Off-line data reduction software attempts 
to match inputs to outputs to construct 
response time pairs. The time difference 
between the input and output is determined 
to measure response time. Unfortunately, 
this process has many inherent problems. 
The primary problem is inaccuracy in the 
matching process. Because no tracing of 
processing steps through the software is 
performed, no identification is recorded 
with a system output to indicate the input 
that triggered it. Thus many mismatched 
pairs are introduced into the process. 
Another problem is the resolution of the 
clock. Both the 9020 system and the HCS 
use a clock with a 0.5-s resolution for 
message logging. Response time measure¬ 
ment accuracy is limited by this resolution. 
The final problem is that for many outputs 
the response time is recorded upon display. 
This produces a measurement of end-to- 
end response time that does not agree with 
the response time requirements (specified 
for the central computer system by itself). 
These problems have all combined over the 
life of the 9020 system to the extent where 
measurements of operational response 
times have never been a trusted measure of 
system performance. 

Recently, the 9020 and HCS response 
time measurement capability has been up¬ 
graded to overcome the most serious prob¬ 
lem—inaccuracy of matching inputs to out¬ 
puts. A detailed rule base was developed 
through interviews with experts in the oper¬ 
ation of the system. More extensive and 
sophisticated rules recognize many con¬ 
ditions that caused the earlier tool to mis¬ 
match messages. The result is a more ac¬ 
curate, although not perfect, measurement 
of response times. It appears that a method 
of directly tracking input to output mes¬ 
sages is the only way to ensure completely 
accurate matching and hence response time 
measurements. 

Several techniques are used for the 
measurement of CPU utilization in the 
9020 and HCS. One technique is to sample 
the busy/not busy state of the CPU to 
estimate utilization. The accuracy of this 
technique has been validated through the 
use of hardware monitors. In order to 
understand the contributors to CPU utili¬ 
zation, a second technique is used. All CPU 
task initiation, suspension, resumption, 
and termination events are recorded during 
operation. The data are reduced to deter¬ 
mine the execution rate and average service 
time of all tasks, which are in turn used to 
produce CPU utilizations by task. Typical¬ 
ly the total CPU utilization determined in 


this manner falls short of the utilization 
determined by the first method. This short¬ 
fall is on the order of 10 percent, which can 
be significant. Therefore, both methods are 
used together and adjustments are usually 
made to the measurements produced by the 
second method. 

Two other important measurement ca¬ 
pabilities are used. Both serve the purpose 
of detailed investigation, understanding, 
and modeling of system behavior. The first 
capability is to produce histograms and 
associated statistics of PE service times. We 
have found that the mean, even when sup¬ 
plemented with the standard deviation, can 
be a very limited measure of system behav¬ 
ior. As an example, multimodal distribu¬ 
tions of service time are not uncommon and 
understanding this phenomenon is often 
critical to accurate modeling of system per¬ 
formance. Secondly, time series representa¬ 
tions of the system behavior can be very 
important. Assumptions of time indepen¬ 
dence of system behavior can be very mis¬ 
leading. Embedded systems having both 
random and deterministic workload ar¬ 
rivals tu'e particularly susceptible to this 
type of behavior. We have found that tools 
that will depict device utilizations and re¬ 
sponse times as functions of time are very 
useful in understanding the behavior of 
such systems. 

One final limitation of the 9020 and HCS 
measurement capabilities has been the 
amount of resources they consume. When 
the 9020 system is processing the highest 
loads, measurement capabilities must be 
turned off because of capacity limitations. 
This is the situation in which measurement 
data is most useful. The HCS has been re¬ 
quired to provide satisfactory response time 
performance at its maximum workload 
with all significant resource monitoring and 
performance measurement capabilities 
operational. 

AAS performance measurement capa¬ 
bilities. Requirements for measurement 
capabilities in the future AAS have been 
specified to overcome previous deficiencies, 
the principal one being inaccuracy. Al¬ 
though accuracy of measurements is an im¬ 
portant requirement, the (computational) 
cost of very accurate measurements can be 
high. Accuracy requirements for the AAS 
measurement capabilities are being spjeci- 
fied to be commensurate with expected 
uncertainties in other components of the 
capacity management system, i.e., work¬ 
load projections and model errors. 
Measurement accuracy requirements will 
eventually range from a few percent for 
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utilizations to 10 percent for response 


As already discussed for the 9020 and 
host computer systems, the achievement of 
accurate measurement of end-to-end re¬ 
sponse times in the AAS is a challenging 
design problem. Many stimuli-response 
pairs may be active at any time. The distrib¬ 
uted nature of the system also complicates 
the tracking of stimuli to responses. Some 
response pairs are interfacility, using long- 
haul communications between facilities. 
Some outputs are generated automatically 
by the system and have either no associated 
response time or a response time measured 
from a time rather than an event. Very 
detailed associations of stimuli to response 
will be required to satisfy the accuracy re¬ 
quirements for AAS response time mea¬ 
surement. 

System level response time measure¬ 
ments indicate compliance with require¬ 
ments. However, such measurements do 
not reveal the nature of response time prob¬ 
lems or indicate potential problems. Mea¬ 
surements of utilization of both active and 
passive resources have been specified to 
identify potential bottlenecks. A require¬ 
ment has also been specified for message 
processing trace histories. Such histories 
record all processing and delays involved in 
producing a single response. 

Our experience with performance mea¬ 
surement of the ATC computer systems 
indicates that performance measurement 
of complex, responsive software systems 
requires detailed measurement of software 
interactions and sequencing in producing 
system responses. In addition, workload 
characterization must be accomplished at 
a detailed level. The ATC computer sys¬ 
tems depend on custom-developed soft¬ 
ware performance measurement capabili¬ 
ties to obtain the level of detail required 
for successful performance assessment 
and capacity management. 


Performance modeling 

Performance modeling is a central com¬ 
ponent of capacity management of ATC 
computer systems. Modeling is used 
primarily to project the performance of 
computer systems in the future. Occa¬ 
sionally, modeling is used to determine per¬ 
formance parameters that are inaccessible, 
inconvenient, or too costly to measure 
directly. The role of performance models 
has become increasingly imptortant in ATC 
capacity management. Their use has evolved 


Ensuring model accuracy 


Workload representation 

• Explicit representation of the 
system workload incorporated in 
the model. 

• Workload representation includes 
probabalistic branching of inter¬ 
nal software tasks/modules. 

Software representation 

• Embedded software design 
faithfully represented by model. This 
permits detailed validation (see below) 
and correlation of design changes/ 
enhancements with model structure. 

• System performance metrics 
(e.g., response times) explicitly 
represented in the model. 

• Detailed service time models 
based on operational settings and 
workload factors. 

Validation 

• Predicted performance 
parameters are compared to mea¬ 
sured values. 


Simulator driver tests: 
Comparison over entire range of 
expected workload, even if this 
range is not currently encoun¬ 
tered in operational conditions. 
Operational validation: 
Comparison to data from opera¬ 
tional installations. Simulation 
driven tests can fail to represent 
important workload parameters or 
combinations of parameters. 
Detailed measures of system 
behavior. 


Compare predicted and measured 
values of such parameters as device 
utilizations, queue lengths, wait time, 
and workload rates. Reduce measure¬ 
ment data to determine behavior that 
is typically unsupported by models 
but that occurs frequently in complex 
systems. Areas to watch are “unusu¬ 
al” service time distributions, arrival 
distributions, or transient, time- 
dependent phenomenon. 


from very limited application in the 9020 
system to a high dependence on modeling in 
AAS design, development, and capacity 
management. 

9020 and HCS performance modeling. 
Performance modeling for the 9020 is based 
on discrete event simulation. A detailed 
model of the 9020 system was developed in 
the mid-1970’s. The model consists of ap¬ 
proximately 10,000 lines of simulation code 
written in the ECSSII language. The model 
has seen limited use in several 9020 capacity 
studies to determine the effects of increased 
workload on 9020 performance. 

The HCS performance modeling capa¬ 
bilities include a discrete event simulation 
model and an analytic (queueing network) 
performance model. The HCS simulation 
model has been adapted from the 9020 
simulation model through changes to 
reflect new processor speed, more memory, 
and faster peripheral devices. The simula¬ 
tion model can be used for detailed investi¬ 
gation of HCS dynamics. 

The HCS analytic model was developed 
to complement the simulation model by 
providing a quick and inexpensive way to 
predict future performance of the HCS at 
many sites under varying workload and 
operational conditions. In this role the 
analytic model is extremely cost effective. 
For example, a case study using the discrete 
event simulation model on an IBM 3033 
uses 15 minutes of CPU time to simulate 30 


minutes of HCS operation. The analytic 
model uses 50 seconds of CPU time on a 
DEC VAX 11/780. A microcomputer 
(IBM PC) version of the analytic perfor¬ 
mance model has also been developed that 
runs in approximately five minutes depend¬ 
ing on the microcomputer configuration. 

A major question in the development of 
the analytic performance model was 
whether analytic techniques could provide 
accurate predictions of response time for a 
system as complex as the HCS. The HCS 
software comprises more than 100 program 
elements and over one-half million lines of 
code. The workload includes the processing 
of over 100 different controller-entered 
messages and several radar data streams. 
Accuracy goals of (1) less than a 20 percent 
error in message class response time projec¬ 
tions, and (2) less than an absolute error of 
10 percent on CPU utilization were estab¬ 
lished for the model. Until these goals were 
realized, it was necessary to continue a par¬ 
allel effort to utilize the discrete event simu¬ 
lation model for the HCS. 

An overview of the HCS analytic perfor¬ 
mance model is shown in Figure 4. The per¬ 
formance model has three components—a 
software model, a workload model, and an 
analytic (queueing network) model. 

The approach taken to modeling the 
HCS centers on the software model compo¬ 
nent. The software model defines the “pro¬ 
cessing threads” within the HCS software. 
Processing threads describe the execution 
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flows of PEs that are triggered in response 
to a stimulus, such as the arrival of a con¬ 
troller message. 

With this approach to modeling the soft¬ 
ware, the PEs are the job classes within the 
queueing network model component. This 
is a logical choice for job classes because the 
PEs have unique service demands and 
scheduling priorities at the CPU. Because 
the software model relates PE performance 
to message processing performance, the 
HCS performance requirement can be esti¬ 
mated. Furthermore, the measurement 
tools provide measurements at both the PE 
and message aggregation levels. 

To characterize the workload for the 
queueing network model, workload pa¬ 
rameters are related to the software model 
of the message execution flows. As 
previously mentioned, the workload on the 
HCS comprises controller messages, radar 


data processing, flight data processing, and 
housekeeping functions. One component 
of the workload model estimates the arrival 
rate of messages under different air traffic 
conditions. The execution frequency of the 
PEs within message processing threads are 
derived by the software model based on the 
execution flow descriptions. The other 
component of the workload model esti¬ 
mates the service demands of the PEs in 
execution flows and for the PEs that exe¬ 
cute periodically to perform housekeeping 
and radar processing. 

These workload parameters are input to 
the queueing network algorithms of the 
analytic performance model component. 
Not all PEs have been explicitly represented 
in the performance model. It was deter¬ 
mined that 95 percent of the workload 
could be represented by 45 of the over 100 
PEs. The workload was therefore truncated 


to simplify the task of representing the 
message processing threads and to shorten 
computation time. The queueing network 
component computes device utilizations 
and PE response time estimates. The soft¬ 
ware model estimates end-to-end message 
class response times by summing the PE 
response time estimates along the execution 
flow paths of the message processing 
threads. 

The HCS model was validated to mea¬ 
surement data from synthetic test work¬ 
loads and from 9020 field data suitably ad¬ 
justed to reflect 9020/HCS differences. The 
results of a synthetic test workload were 
also compared to the results of the detailed 
discrete event simulation model. These 
comparisons of four different classes of 
message types are summarized in Table 2. 
The model results were validated to 
measurement data to within the 20 percent 
accuracy requirement. The analytic model 
results were comparable to the results of the 
simulation model. Furthermore, the 
analytic and simulation model results cor¬ 
related to within a 15 percent difference. 

Whether the HCS could be adequately 
modeled using an analytic approach was a 
major issue. This effort has shown that the 
analytic approach can provide perfor¬ 
mance predictions of useful accuracy. (See 
Ensuring Model Accuracy sidebar.) The 
analytic model is now being used for 
specific capacity management and planning 
applications and is now a cost-effective 
alternative to the discrete event simulation 
model. 

AAS performance modeling. Perfor¬ 
mance models are being used as an integral 
part of the design and verification process 
for the AAS as well as for long-term capaci¬ 
ty management. Models are used during 
system design to verify that the AAS design 
will meet performance requirements while 
processing the specified workload. AAS 
performance models predict system levels 
of performance (response time) and de¬ 
tailed performance metrics reflecting the 
operation of software and hardware com¬ 
ponents. The models take into account the 
evolutionary nature of the AAS—air traffic 
increases, functionality changes, facility 
consolidation, and changes in geographical 
and temporal distribution of air traffic. 
While choice of modeling approach and de¬ 
velopment of the models is the responsibil¬ 
ity of the individual AAS contractors, these 
activities are proceeding from top-level 
AAS performance modeling requirements. 

The primary requirement placed on the 
models is accuracy. To be of use the models 
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Table 2. Comparison of analytic model results to discrete event simulation model 
results and response time measurements. 


Message 

class 

Analytic 
model 
response 
times (s) 

Simulation 
model 
response 
times (s) 

Percent 
difference 
analytic vs. 
simulation 

Measured 

response 
times (s) 

Percent 
difference 
analytic vs. 
measurements 

I 

0.99 

1.02 

-3 

0.96 

3 

11 

0.77 

0.84 

-8 

0.82 

2 

111 

1.98 

2.02 

-2 

2.24 

-12 

IV 

2.42 

2.10 

15 

2.07 

17 


must provide accurate predictions of 
system performance. Models used during 
design and development are required to 
have an accuracy of 20 percent for response 
times and utilizations. This value was 
chosen based on a balance of desired and 
achievable model accuracy. Twenty percent 
is compatible with other system uncertain¬ 
ties and so is not a dominant uncertainty in 
the design process. It is also an accuracy 
achievable within the state of the art of per¬ 
formance modeling. Establishment of the 
requirement provides guidance in decisions 
of modeling approach and development. 
As the AAS design progresses, the perfor¬ 
mance models can begin to use test data in 
place of estimates of resource consumption 
and details of system operation. As the 
model incorporates more detail and test 
data, accuracy is required to increase. Ac¬ 
curacy for models after measurement data 
become available is specified to be 5 percent 
for device utilizations and 10 percent for 
response times. This degree of accuracy 
provides data that can be used for capacity 
management decisions. 

Requirements have also been placed on 
the use of performance models during 
design and development. Overall, the AAS 
contractors are required to justify design 
decisions based on performance model 
results. For example, performance models 
have been used to assess the performance of 
the IEEE standard LAN protocols with 
respect to specific AAS workload and 
response time requirements. At the next 
level of design, processing and response 
time budgets are being established for soft¬ 
ware and hardware components. Perfor¬ 
mance models are used to verify that these 
budgets satisfy system-level performance 
requirements. As the design evolves, 
designers and implementors are improving 
estimates of processing resource consump¬ 
tion. The models are used to translate these 
estimates into system-level performance 
projections, identifying problems areas as 
they arise. The same use is made of the 
models as unit-level test data becomes 
available. 

The use of the models does not stop when 
the system-level test data is available. 
Because of the complexity and evolutionary 
nature of the AAS, it is not possible to test 
every possible AAS configuration, work¬ 
load scenario, and implementation of 
future functionality. Instead, models are 
used to extend the test results to the full 
spectrum of anticipated AAS conditions. 
In this manner, models are used to comple¬ 
ment testing in a comprehensive AAS veri¬ 
fication program. Of course, before such 


use is made, the models are required to first 
be validated to test results. 

Performance models used in capacity 
management will evolve from the models 
developed to support AAS design and im¬ 
plementation. Performance models used 
for capacity management are required not 
only to be accurate, but also to be efficient. 
The latter requirement is derived from the 
many different facilities, configurations, 
and workloads that must be considered in 
capacity management of the AAS. 

Capacity management 
program 

The implementation and operation of a 
capacity management program has evolved 
from very limited beginnings in the 9020 
system to requirements for a comprehen¬ 
sive AAS capacity management program. 
There was basically no capacity manage¬ 
ment program for the present 9020A or 
9020D computer systems at the en-route 
sites. At least half of the 9020 systems had 
been reaching capacity limits for the past 
three years (i.e., processor utilizations were 
exceeding 80 percent with significant in¬ 
creases in response times). An annual pro¬ 
gram to measure processor, channel, and 
storage utilizations had been conducted by 
the FAA Technical Center, evaluating the 
effects of traffic increases and software 
enhancements (new releases) to the peak 
traffic conditions. However, measurements 
at peak traffic conditions could not be ob¬ 
tained because data collection programs 
were shut off when the processor utilization 
exceeded 80 percent. Additionally, no 
reliable means of projecting performance 
into the future was available. 

To correct this shortfall, a capacity 
management program for the HCS is under 
development and will be in place in 1987. 
The program will use the analytic perfor¬ 
mance model to provide predictions of 
HCS utilizations based on extrapolations of 
the present track loads out to the year 1995. 


The model can be tailored to each field site 
with the site’s own adaptation (e.g., 
number of radars, sector suites, traffic 
loads, etc.) so that potential capacity prob¬ 
lems and recommendations on future up¬ 
grades can be provided on an individual 
basis to these sites. Major components of 
this capacity management program are 

(1) The utilizations from the annual 
measurements at each site. 

(2) Data reduction and analysis of the site 
measurement data (performance and 
workload) to compare predicted with 
observed performance and to provide up¬ 
dated inputs to the analytic model. 

(3) Use of the model to produce predic¬ 
tions (in two-year intervals or when major 
software enhancements are planned) of 
performance to identify the possible onset 
of capacity limitations. 

A capacity management program for the 
future AAS is now under development. 
The program is particularly important 
because the AAS is required to evolve dur¬ 
ing its lifetime to handle increased air traffic 
and automated ATC support functions. 
The AAS capacity management program 
will specify procedures for ensuring 
satisfactory delivered service levels. The 
AAS contractors are developing a capacity 
management program plan defining the 
tools and procedures to be used. Measure¬ 
ment capabilities will be routinely used to 
measure workload and system response 
time performance. Data will be maintained 
in a centralized database for analysis. 
Measured values will be compared to 
predicted values, analyzed, and reported. 
Models will be used to extrapolate 
measured values to future years, functional 
enhancements, and operational pro¬ 
cedures. The projected values will be com¬ 
pared to requirements to identify can¬ 
didates for upgrade. 

Capacity plans will forecast the delivered 
service levels at each AAS facility .The first 
set of plans is now being developed by the 
AAS contractors. The plans will be a major 
product of the capacity management pro- 
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gram. Plans show the forecast utilization of 
system resources and expected perfor¬ 
mance for each AAS computer system. 
Plans must reflect forecasted workload 
changes as well as planned changes in 
system configuration. The first increments 
of the AAS computer systems are specified 
to have a minimum capacity to support five 
years of evolution. Beyond this point, the 
contractors are developing the best tech¬ 
niques for providing additional capacity to 
support increased workload and func¬ 
tionality. 

O ur activities in capacity manage¬ 
ment of the evolving ATC com¬ 
puter systems have demonstrated 
methods of performance and workload re¬ 
quirements specifications, measurement 
capabilities, and modeling tools that may 
be useful in any embedded computer 
systems application. Performance require¬ 
ments should be specified in terms of opera¬ 
tional conditions. Since workload specifi¬ 
cations are required for capacity and 
response time testing, they should accurate¬ 
ly reflect field conditions. All key workload 
parameters should be included and unreal¬ 
istic conditions eliminated. Because it is im¬ 
portant to keep the workload requirements 
up to date for capacity planning, the pro¬ 
cess of workload specification should be 
made as efficient as possible to easily ac¬ 
commodate changes in future workloads. 
Automation of this process has helped. 
Furthermore, in an evolving system, the 
early development stages of future 
enhancements should include definition of 
the parameters needed for workload 
specification so that early performance 
evaluation can be achieved. 

Measurements should be capable of be¬ 
ing made even under full load conditions. 
Measurement accuracy should be consis¬ 
tent with current and anticipated perfor¬ 
mance requirements. Measurement data 
help to determine whether requirements are 
being met. To solve performance problems, 
e.g., identify bottlenecks, often requires 
detailed and disaggregated measurements. 
Time series representation of system 
behavior can be important to understand¬ 
ing the performance of embedded systems. 
The capability to produce histograms 
associated with service times is also useful. 
Performance measurement requirements 
for capacity management of complex 
embedded systems may require carefully 
designed, custom software. 

Performance models should be consis¬ 
tent with workload specifications and 
measurement capabilities. Validation of 


models is very impPrtant. If possible, 
models should be validated over the entire 
range of anticipated system loading and to 
operational measurement data. Analytic 
models can be developed for complex 
systems that produce satisfactory predic¬ 
tion accuracy and are efficient to operate. 
The development of these models should be 
based on a detailed understanding and 
representation of the embedded system 
software. □ 
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Can we trust the new 
AAS to deliver highly 
dependable air traffic 
control services until 
the year 2000? Yes, 
systematic application 
of fault tolerance 
offers a solid promise 
of success. 
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T he Advanced Automation System, 
or AAS, will provide automation 
services to both en-route and ter¬ 
minal air traffic controllers throughout 
the United States. Although controllers 
are able to maintain separation between 
aircraft during periods of interruption of 
the automatic services, the transition to 
backup modes of operation is potentially 
hazardous. The increased controller 
workload resulting from interruption of 
the services provided to controllers limits 
the traffic handling capability of the Air 
Traffic Control System, which can result 
in major delays during periods of heavy 
traffic. As the level of automation services 
provided to controllers increases, 
interruption of computer services to the 
controllers will become even more critical. 
Accordingly, extremely high reliability 
and availability of the services provided by 
the AAS will be required on a continuous 
basis, 24 hours a day, seven days a week. 

Reliahility of the 
present system 

The 9020 system. The system currently 
in use in the air route traffic control 
centers, or ARTCCs, is the IBM 9020 
System, a modified configuration of IBM 
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System 360 computers. * This system con¬ 
tains fault-isolation and recovery features 
that were state-of-the-art when the system 
was developed in the mid-sixties. How¬ 
ever, the system design is mainly oriented 
toward tolerance of hardware faults, and 
the 9020’s highly centralized architecture 
and pooled memory design remained vul¬ 
nerable to software faults. Over the past 20 
years, the software has stabilized and 
changes have been judiciously introduced 
and verified through testing and mainte¬ 
nance. A failure of the 9020 system results 
in the interruption of computer services at 
all controller operating positions. In this 
event, the ATC system relies on the in¬ 
dependent backup capabilities of the 
direct access radar channel, or DARC, 
controller-pilot voice communications, 
and flight data strips, as discussed below. 

Although the computer complex is 
often referred to as an automation system, 
the services provided by it are far more 
than automation services; other than voice 
communication, it is the controller’s 
primary contact with the airspace being 
controlled. After interrupting air traffic 
control processing, the 9020 attempts to 
isolate the failure, reconfigure the system 
if necessary, and restart ATC processing. 
If automatic recovery is successful, ATC 
processing is interrupted for 20 to 60 
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seconds. If automatic recovery is not suc¬ 
cessful, an unscheduled outage occurs. 
The mean time to restore service following 
an unscheduled outage is approximately 
20 minutes, while the mean time between 
failures is about 600 hours. 

Broadband backup. When the 9020 was 
first introduced, the only backup available 
to controllers in the event of a computer 
outage was to revert to unprocessed 
broadband radar data. To convert to the 
use of broadband radar, each controller 
had to rotate his or her cathode ray tube 
display to a horizontal position and re¬ 
identify all radar targets using small 
plastic chips called “shrimp boats” and a 
grease pencil. The most critical time 
following a computer failure was during 
this transitional period. The wide varia¬ 
tion in 9020 recovery times further com¬ 
pounded the problem because controllers 
had no way of knowing how long to wait 
for the computer system to recover before 
deciding to switch to the broadband radar 
system. 

Direct access radar channel. Subse¬ 
quently, a new backup system called the 
direct access radar channel, or DARC, 
was developed. This system, which be¬ 
came operational in 1981, is an indepen¬ 
dent computer system that bypasses the 
9020 central computer, providing an alter¬ 
nate path for radar data to the controller’s 
display. This backup system can be quick¬ 
ly activated and provides an automatic 
tracking capability so that the controllers 
no longer have to resort to tracking the air¬ 
craft manually by pushing plastic chips 
across the screen. 

Although the DARC system provides a 
significantly improved backup capability 
for the 9020, it was not designed to provide 
higher-level functional aids to the con¬ 
troller, such as conflict alert, and therefore 
is only a short-term backup. 

Evolution of AAS RMA 
requirements 

Procurement of the AAS is being con¬ 
ducted in accordance with the Office of 
Management and Budget policy for major 
system acquisitions, expressed in OMB 
Circular A-109. ^ The policies in A-109 are 
intended to “place emphasis on the initial 
activities of the system acquisition process 
to allow competitive exploration of alter¬ 
native system design concepts in response 
to mission needs” (OMB Circular A-109, 


p. 3). System requirements are to be de¬ 
fined in terms of the operational charac¬ 
teristics needed by the users of the system, 
not in terms of equipment specifications. 
The objective is to allow industry the free¬ 
dom to develop Innovative solutions to 
government needs in a competitive envi¬ 
ronment. Contractors should not be re¬ 
stricted by a preconceived system concept 
or by forced compliance with government 
specifications and standards. The require¬ 
ments in an A-109 acquisition are to be ex¬ 
pressed as functional requirements, not 
equipment requirements. 

In the AAS procurement, this emphasis 
on functional requirements has been ex¬ 
tended to the reliability, maintainability, 
and availability (RMA) characteristics, 
traditionally expressed in equipment terms 
but now specified in terms of delivery of 
service. 

In this article, we will discuss only the 
main element of the AAS, which is the 
area control computer coupler, or ACCC. 
The approach used to define the ACCC re¬ 
quirements illustrates the approach used 
for the other computer complexes as well. 

Concept of operating modes. The 
overall ACCC system availability should 
approach unity. However, htu'dware and 
software element failures may occur 
within the system that could temporarily 
prevent the system from performing all of 
its required functions. Therefore, a hierar¬ 
chy of three levels of functional perfor¬ 
mance has been defined. 

The highest level of functional capabili¬ 
ty is the full-service mode. In this mode, 
the ACCC performs all of its designated 
operational functions within the required 
response times. 

If failures within the system have caused 
some services provided to controllers to be 
interrupted, while the rest are operating 
properly, the system is said to be in the 
reduced-capability mode, provided that a 
specified minimum level of performance is 
maintained. This minimum level or 
“floor” of the reduced capability mode 
provides all of the basic capabilities re¬ 
quired to perform ATC functions, in¬ 
cluding surveillance, automatic tracking, 
automatic hand-off, and flight plan pro¬ 
cessing, but does not include many of the 
more advanced automation capabilities 
available in the full-service mode. This 
level provides the functional capability 
that enables the facility to maintain a safe 
and orderly flow of traffic for an in¬ 
definite period of time, although airspace 
users may experience some inconve¬ 


niences, such as not being able to fly 
preferred routes or altitudes. 

When the minimum level of perfor¬ 
mance required for the reduced-capability 
mode cannot be maintained, the system is 
said to be in the emergency mode. In the 
emergency mode, the most critical services 
of surveillance, automatic tracking, and 
local flight data update are provided. 
These functions enable the controllers to 
continue to maintain separation between 
aircraft—the most critical function of the 
ATC system. However, the increased 
bookkeeping workload resulting from the 
loss of automatic processing of flight plan 
data would make it impossible for the con¬ 
trollers to maintain a high volume of traf¬ 
fic for any length of time. In the event of a 
sustained outage of the ACCC, respon¬ 
sibility for the aircraft under the control of 
the failed facility will be assumed by adja¬ 
cent facilities. This concept, known as 
facility backup, is the ATC system’s 
defense against the catastrophic failure of 
an ACF, when it is due to other causes, 
such as fire or earthquake. Thus, the 
emergency mode is intended primarily to 
provide for the continuity of essential ser¬ 
vices during the transition to facility 
backup or a return to the full-service or 
reduced-capability modes of operation. 

Transparent recovery. The objective of 
the AAS is to make all recovery actions 
transparent to the controllers. In order to 
quantify the meaning of “transparent,” it 
was necessary to establish the system’s 
normal response time requirements. If the 
system could recover from a failure and 
still respond within the required response 
time interval, then the controllers would 
not be able to detect any interruption of 
service and the recovery could be con¬ 
sidered transparent to the user. Therefore, 
the system must be designed to perform all 
required processing within the designated 
maximum response times, as well as any 
automatic recovery actions necessitated by 
hardware or software failures. If the 
system recovers within the mtiximum re¬ 
sponse times, the ATC services are not 
considered to be interrupted. Exceeding 
these response times for any reason will re¬ 
sult in perceptible delays in the informa¬ 
tion being presented to the controllers and 
will be counted as downtime, which re¬ 
duces the availability of the services 
provided. 

Definitions of failure. The definition of 
a system failure in the AAS derives from 
the concept that if the system fails to re- 
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Table 1. ACCC availability requirements. 



Goal 

Requirement 

Full-service mode 

1.0 

.999995 (2.6 min/yr) 

Reduced-capacity mode 

1.0 

.999999 (32 s/yr) 

Emergency mode 

1.0 

.9999999 (3 s/yr) 

Operational position 

.999999 (32 s/yr) 

.999995 (2.6 min/yr) 


spond to a controller’s request, then from 
the user’s viewpoint the service requested 
is unavailable. The reason for the unavail¬ 
ability is of little concern to the user. 
Therefore, failures are defined with respect 
to the inability to provide a required ser¬ 
vice within the specified response time. 

In addition to a hardware or software 
failure, a response time failure can result 
from an accumulation of processing, recov¬ 
ery, and restoration time delays. Failures 
are thus defined with respect to the system’s 
functional requirements and are indepen¬ 
dent of the equipment configuration. 

An operational-position failure occurs 
whenever the set of logical displays and 
associated input and control capabilities 
associated with that position cannot be 
provided within the specified response 
time. A system-level mode failure occurs 
whenever any specified maximum response 
time is exceeded at two or more opera¬ 
tional positions. 

AAS response time performance is 
specified in terms of a mean, ninety-ninth 
percentile, and maximum response time 
associated with each of a set of response 
time classes. If a failure occurs within the 
system and recovery is performed quickly 
enough to permit the response to be pro¬ 
vided within the specified maximum, then 
no system level failure has occurred. Ex¬ 
ceeding the maximum response time re¬ 
sults in accumulated downtime and 
reduces the system availability accordingly. 

Quantitative requirements. Availability 
of ATC services is considered the most im¬ 
portant consideration in the design of the 
AAS. The overall design goal is to provide 
safe, full-service operation within the re¬ 
quired response times, 100 percent of the 
time. Although hardware and software 
element failures can be expected to occur 
within the system, fault tolerance 
(automatic fault detection, isolation, and 


recovery) along with judicious functional 
partitioning will be utilized to assure the 
availability of essential functions and to 
minimize full-service interruptions. 

The AAS system availability require¬ 
ments in the system-level specification are 
stated in terms of the probability of having 
at least a given level of functional capabil¬ 
ity (operating mode) available to the air 
traffic controllers. The requirements thus 
address the availability of ATC services to 
the system’s users and do not necessarily 
represent the availability of specific equip¬ 
ment configurations. 

The ACCC availability requirements 
appear in Table 1. The figures in paren¬ 
theses translate the requirements into the 
average amount of time per year that the 
functional capability associated with a 
given mode or position would be 
unavailable. Thus, for 3 seconds per year 
the system may be completely down and 
the controllers will be without the essential 
surveillance and tracking functions de¬ 
fined for the emergency mode. For 28 
seconds per year the system may be 
operating at the emergency-mode level of 
capability. For 2.1 minutes per year the 
system may be operating at or above the 
minimum capability required for the 
reduced-capability mode, but below full 
service. The sum of these times cor¬ 
responds to 2.6 minutes per year of full- 
service unavailability. Of course, the 
nature of the availability parameter means 
that the “downtime per year’’ is the 
average taken over an infinitely long time. 
Depending on the frequency of failure, the 
actual duration of outages could be longer 
or shorter than the average. 

It is important to note that the 
availability requirements are stated with 
the assumption that the system is fault 
tolerant, and that recovery management 
remains in control during the reduced- 
capability and emergency modes. Under 


this assumption, the availability re¬ 
quirements define the hardware element 
redundancy needed to avoid system 
outages due to the exhaustion of hardware 
resources. 

In addition to the availability re¬ 
quirements, specific reliability constraints 
have been imposed to limit the maximum 
allowable frequency of failure to one full- 
service mode failure every four weeks and 
one operational position failure per year. 

Qualitative requirements. To ensure 
that the frequency and duration of service 
interruptions are minimized and system 
safety is maintained, additional qualita¬ 
tive reliability and maintainability design 
criteria were specified. The additional 
criteria make the use of fault tolerance im¬ 
perative. The reliability design criteria ad¬ 
dress the avoidance of single points of 
failure and the functional partitioning of 
the system so that when service interrup¬ 
tions are unavoidable, the number of 
functions and operational positions af¬ 
fected are limited to operationally 
tolerable levels. The maintainability 
design criteria address features and tech¬ 
niques that will enable the rapid detection, 
isolation, repair, and recertification of 
failed items. In order for a repairable, 
fault-tolerant system to meet its reliability 
and availability potential, virtually all 
necessary maintenance actions must be 
performed immediately and quickly, so 
that the failed item can be restored to 
operational status before additional 
failures exhaust the available spares and 
result in a system failure. 


Advances in fault- 
tolerant system design 

In the two decades since the initial 
design of the 9020 system, significant pro¬ 
gress has occurred in the design and suc¬ 
cessful implementation of highly depen¬ 
dable, fault-tolerant systems for several 
important applications, including space¬ 
craft and aircraft control, telecommunica¬ 
tions, process control, and transaction 
handling. 

Much progress has been made in defin¬ 
ing the coverage concept with its many 
aspects that quantize the effectiveness of 
fault-tolerance mechanisms within a 
design. Strong new insights have been 
gained in fault modeling, error detection, 
fault location and removal, and system 
state restoration techniques. Many of 
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these techniques have been implemented 
at the hardware level, especially in VLSI 
technologies. * 

Pioneering work has been done in the 
study of design diversity techniques for the 
tolerance of design faults, including 
recovery blocks and N-version program¬ 
ming for software,’ and diverse multi¬ 
channel computation for hardware. * 

Most important of all, the insights gained 
during the research and design processes 
have led to the convergence of many 
diverse viewpoints into a cohesive frame¬ 
work of concepts of dependability and 
fault tolerance. * The existence of such a 
framework makes it possible to approach 
the design and subsequent evaluation of 
the AAS with a structured design ap¬ 
proach that integrates the performance 
and fault-tolerance goals during the evolu¬ 
tion of system architecture. The AAS is by 
far the most complex system yet specified 
that depends on fault tolerance for its 
viability, and highly structured design is of 
critical importance for the successful im¬ 
plementation of its fault tolerance. 


Current challenges and 
problems 

Concurrently with the successes dis¬ 
cussed above, new and difficult problems 
in fault tolerance arose from the rapid 
evolution of large distributed computing 
systems and the growing complexities of 
their individual nodes that were made 
possible by the application of VLSI 
technology. 

Foremost among the new threats to 
system dependability we find the follow¬ 
ing challenges: 

(1) The need to tolerate new fault 
modes unique to distributed systems, even 
though they lead to errors in synchroniza¬ 
tion and in state consistency of concurrent 
processes and distributed databases, mak¬ 
ing system state recovery very difficult. 

(2) The need to tolerate residual design 
faults that remain undiscovered by testing 
and validation of software or VLSI logic, 
and later may cause concurrent, identical 
errors in multiple redundant computing 
channels. 

(3) The need to cope with unantici¬ 
pated, failure-inducing improper inter¬ 
actions of otherwise well-designed fault- 
tolerant subsystems that have not been 
perfectly integrated into a distributed 
fault-tolerant system. Especially difficult 
to integrate are the various hierarchical 


fault diagnosis and recovery sequences 
that support the localized fault tolerance 
of subsystems and those that support the 
fault tolerance of functional services 
(“threads”) provided by two or more sub¬ 
systems. 

(4) The need to handle more than one 
nearly concurrent fault manifestation. 
The large size and distributed nature of 
new systems lead to the possibility of two 
or more independent fault manifestations 
occurring at nearly the same time. This, in 
turn, will require two or more recovery 
algorithms to be concurrently active, with 
the resulting risks of mutual interference, 
deadlocks, and unpredictable behavior. 

In ATC systems, for which long service 
life is a critical goal, one additional specific 
challenge is the need to deal with changes 
to a hierarchy of error-handling mechan¬ 
isms. For this reason the FAA is making 
an investment in the AAS design competi¬ 
tion phase, or DCP, to ensure that in¬ 
herent robustness and extensibility are in¬ 
corporated in the design. It is recognized 
that this requires a balancing of fault 
tolerance extensibility and ATC service ex¬ 
tensibility concerns in order to ensure that 
ATC service changes made to the AAS de¬ 
sign are also reflected as extensions to the 
fault tolerance mechanisms. 


Assuring the availability 
and safety of the AAS 

Obviously, the AAS is a distributed 
system of high complexity and therefore 
likely to be affected by all the problems 
discussed above. The choice of AAS 
dependability goals and of the means to 
verify their attainment by an AAS design 
have undergone evolutionary changes 
over the past two years. We summarize the 
current view of the major dependability 
goals for the AAS below. 

The quantitative reliability/maintain¬ 
ability/availability, or RMA, require¬ 
ments in the AAS system level specifica¬ 
tions^ set goals for the system assuming 
that very complete fault-tolerance provi¬ 
sions are made in the design. Availability 
goals are set with the expectation that 
system recovery management will always 
remain in control, but that some excep¬ 
tionally difficult recovery sequences will 
reduce the services that remain available to 
the air traffic controllers from the stan¬ 
dard full-service mode to those defined as 
reduced-capability mode and emergency 
mode, respectively, for short periods of 


However unlikely, there exists the possi¬ 
bility of a “collapse” of system recovery 
management capabilities. This may lead to 
the temporary outage of the central portion 
of the system. In this event, air traffic con¬ 
trol would revert to emergency mode oper¬ 
ations and manual methods to avoid any 
impact on system safety. The facility back¬ 
up by adjacent ATC centers is provided to 
maintain safety in the case of natural 
disasters, such as floods and earthquakes. 

The near-lOO percent availability of the 
AAS system is attainable through the pur¬ 
suit of three design goals: 

(1) The system should contain suffi¬ 
cient hardware element redundancy to 
avoid system outagesdue to exhaustion of 
hardware resources. 

(2) The design should incorporate a 
hierarchy of complete, protected, and suf¬ 
ficiently fast error detection, fault loca¬ 
tion, and state recovery algorithms for 
every defined class of faults within the 
system in order to provide near-unity fault 
coverage. Design faults should be consi¬ 
dered, and the possibility of nearly con¬ 
current manifestations of two (or more) 
faults in the subsystems of the AAS should 
be taken into account. 

(3) There should exist error detection, 
containment, and system state recovery 
features in the system and application 
software to provide fast-reacting defenses 
against the consequences of the antici¬ 
pated, but not precisely definable, forms 
of abnormal behavior that may be caused 
by unrecognized fault modes and by im¬ 
proper interaction of multiple recovery se¬ 
quences, as discussed previously. 

To attain these goals the FAA has tasked 
the design competition phase, or DCP, 
prime contractors to provide evidence that 
their design includes mechanisms for de¬ 
tecting and recovering from the known set 
of possible faults. This requirement may 
be described in terms of a coverage valida¬ 
tion process, as illustrated in Figure 1. 

In the AAS contract each DCP prime 
contractor is required to identify, through 
failure mode effects analysis, or FMEA, 
and a fault tree analysis, those fault events 
(including potential failures) that are an 
inherent consequence of the functional 
partitioning, and those potential failures 
that may result from deficiencies in 
automatic fault isolation and recovery 
mechanisms and techniques. Further¬ 
more, design modifications to eliminate or 
control critical failures shall be identified 
and introduced into the design process 
throughout the design evolution. 
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As Figure 1 indicates, each type of fault 
is covered by one or more layers of protec¬ 
tion. In fault tolerance these layers com¬ 
prise a hierarchy of error detection/ 
recovery mechanisms that might range 
from memory error correction (SEC/DED) 
logic at the module level through 
application-specific error recovery block 
algorithms, and finally to an independent 
monitor that detects faults in processing 
threads (that span distributed processors) 
and initiates operations on backup 
resources. 

Each layer or layers in the hierarchy 
represent an allocation of functions to 
subsystems and processors or stations in a 
distributed network (shown in Figure 1 as 
“System architecture”). The consequence 
of this design allocation is the capture of 
critical detection and recovery decisions by 
each prime contractor in the failure mode 
effects analysis and fault tree analysis that 
are to be presented in a System Safety 
Report. 

The Software Requirements Specifica¬ 
tion and Software Top Level Design 
Document represent specifications for 
each computer software configuration 
and item identified by the prime contrac¬ 
tor. Each major software item contains an 
allocation of both fault-handling respon¬ 
sibilities and error detection/recovery ac¬ 
tions that were identified by the system 
safety analysis. The software error detec¬ 
tion/recovery requirements and designs 
contained in these documents represent 
the contractor’s approach to achieving 
fault tolerance and a balanced implemen¬ 
tation of mechanisms that eliminate or 
contain the effects of identified classes of 
faults. 


Verifying the fault 
tolerance of the AAS 

The most difficult question that remains 
to be answered after the fault-tolerant 
design approach (discussed above) has 
been defined is “How closely does a pro¬ 
posed AAS design eome to the complete 
attainment of these objectives?” 

Four fundamental techniques need to 
be applied here in order to gain confidence 
in the design and to eliminate residual im¬ 
perfections of its defense mechanisms. 
These techniques are 

(1) The rigorous application of a highly 
structured design process, expressed in the 
form of a design paradigm for fault-toler¬ 
ant systems. 

(2) The documentation (empirical 


modeling) of the design by means of a 
complete, integrated, structured specifica¬ 
tion of all fault-tolerance assumptions and 
fault-tolerance attributes of the entire 
AAS system that makes it possible to 
assess the design for completeness, con¬ 
sistency, and the coverage of defined 
faults. The major elements of such a 
specification are fault definitions, parti¬ 
tioning for error containment, fault- 
detection techniques, diagnostic pro¬ 
cedures, recovery sequences and their in¬ 
tegration, system state restoration, and 
validation of recovery. 


(3) The judicious use of state-of-the-art 
analytic reliability and performance 
modeling techniques to assure the 
presence of sufficient hardware resources. 
Modeling also serves as a designers’ tool 
for the refinement of the AAS design for 
fault tolerance, especially by the modeling 
of various coverages and of perfor¬ 
mance/fault tolerance trade-offs and in¬ 
terrelationships. 

(4) The development, maintenance, 
and continuing use of a set of software 
V&V software, system testing, evaluation, 
and maintenance tools to assure the 



Figure 1. Process for design validation of coverage. 
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growth of AAS software and system 
reliability, availibility, and safety. 

The application of the above techniques 
began with the start of the AAS design 
competition phase, and will need to con¬ 
tinue throughout the entire life cycle of the 
AAS system. Extensions of the ATC ser¬ 
vice as delivered by the AAS are expected 
throughout the entire 20- to 30-year life cy¬ 
cle of the AAS system. They will consist of 
subsequent refinements of existing func¬ 
tions as well as of the addition of new ATC 
capabilities. ’' The protection of the AAS 
system that is offered by fault tolerance 


techniques needs to be systematically ex¬ 
tended with every improvement and addi¬ 
tion of ATC functions. For this reason, 
the verification that is offered by fault 
tolerance techniques needs to be system¬ 
atically extended with every improvement 
and addition of ATC functions. For this 
reason, the verification that fault 
tolerance of the AAS system has remained 
intact and able to meet the dependability 
goals is a capability that needs to remain 
intact and be continuously refined as long 
as the AAS system remains operational. 

The attainment of a system that will 


satisfy the FAA’s rigorous RMA re¬ 
quirements demands constant attention 
throughout the design, development, and 
testing of the AAS. The selection of a 
hardware architecture that has well- 
characterized fault tolerance provisions 
and adequate levels of redundancy to meet 
the RMA requirements is only a first step. 

During the development of the AAS 
software, advanced software development 
tools and techniques need to be used to 
reduce the number of design faults and to 
structure the software for improved 
testability. Following software develop¬ 
ment, an effective reliability growth pro¬ 
gram must be instituted to remove as many 
of the remaining design faults as possible. 
In order to accelerate fault removal it will 
be necessary to simulate realistically a 
heavy system workload to increase the rate 
at which latent faults are exposed. In addi¬ 
tion, effective data reduction and analysis 
tools must be developed to characterize 
the causes of system failures and to 
facilitate the removal of design faults. 

The AAS goal of neary-unity availabil¬ 
ity makes it clear that fault-tolerant 
design, quality control during software 
development, and an effective “test, 
analyze, and fix” program for reliability 
growth will all be essential. Accordingly, 
during the AAS design competition phase, 
the FAA has placed considerable emphasis 
on “front-end” investment in the tools 
and techniques that will facilitate the im¬ 
portant downstream development and test 
activities necessary to assure the availabil¬ 
ity and safety of the AAS. 


T he AAS system is unique among 
current large-scale systems be¬ 
cause of its exceptional availability 
requirements during a long service life and 
because of the early and rigorous emphasis 
on fault tolerance as the main means to 
assure such availability. 

It is evident that a successful delivery of 
the AAS as a replacement of the current 
ATC system will not only provide a new 
level of dependability and safety for air 
traffic control in the United States but will 
also serve as the major milestone in the 
evolution of a new generation of fault- 
tolerant systems. The timely transfer of 
the AAS experience to benefit other large- 
scale system projects remains an impor¬ 
tant challenge to the FAA, the industrial 
contractors, and the research community 
at large. □ 
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Special Feature 


Modeling and Managing 
CAD Databases 


Mohammad A. Ketabchi, Santa Clara University 
Valdis Berzins, University of Minnesota 


Although designers 
rarely pay much 
attention to data 
management, an 
effective DBMS- 
one that meets 
the modeling 
requirements of the 
design process— 
could increase 
their productivity. 


C omputer-aided design operations 
create large amounts of data, of¬ 
ten shared by designers who do not 
want to concern themselves with the de¬ 
tails of data and storage structures. Effec¬ 
tive management of data created in CAD 
operations should increase the productivi¬ 
ty of these operations. 

This article concerns the management 
of data created in the computer-aided 
design of objects, and assemblies of ob¬ 
jects, with regard to the iterative, ten¬ 
tative, and multistage nature of the design 
process. Because of the iterative nature of 
the design process, designers cannot give a 
complete description of the design at once; 
they provide a partial description, later 
completed by repeated refinements. 
Because of the tentative nature of the 
design process, each iteration may contain 
several apparently correct refinements, 
but what seems correct at a given iteration 
may later turn out to be incorrect. 
Designers usually choose one alternative 
and proceed until they complete the 
design. If that alternative turns out to be 
inappropriate, they back up and pursue 
another alternative. The iterative and ten¬ 
tative nature of the design process implies 
several descriptions of the design object in 
the database at any time, and previous 
states of the design must be available to the 
designers working on the later states. 


Three characteristics of the design ob¬ 
jects interact with the iterative and ten¬ 
tative nature of the design process in a 
manner that further complicates the prob¬ 
lem of management of the design data. 
First, design objects are usually assemblies 
of parts that can themselves be composed 
of smaller parts; any modification of a 
part can lead to modifications of assem¬ 
blies using that part. Second, the design 
object is described at the type level first, 
then instantiated and analyzed, and finally 
tuned and adjusted in response to the 
results of analysis. A design object may be 
modified at the type level or after instan¬ 
tiation. Third, a design object has dif¬ 
ferent aspects. The descriptions of some 
aspects are given by the designers, while 
the descriptions of others are derived from 
the given descriptions. For example, logic 
circuits have functional, logical, layout, 
and transistor aspects. 

The current database management sys¬ 
tems, developed with business-oriented 
applications in mind, do not meet the data 
modeling requirements arising from the 
iterative, tentative, and multistage nature 
of the design process, and the multi-aspect 
nature of design objects that are assem¬ 
blies of other objects. 

The deficiencies of current DBMSs in 
design applications and in the modeling 
and managing of refinements, alter- 
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natives, and versions of assemblies were 
recognized early in the history of design 
automation. Many engineering organiza¬ 
tions and researchers have sought solu¬ 
tions for achieving effective management 
of design databases. 

Four different approaches to the solu¬ 
tion exist: 

(1) Developing a new DBMS, called a 
design DBMS (DDBMS), equipped 
with facilities required in design 
applications. 

(2) Enhancing the current DBMSs by 
adding new capabilities. 

(3) Building a layer of software on top 
of current DBMSs to compensate 
for their deficiencies. 

(4) Using a special-purpose file man¬ 
ager that views the DBMS as an 
application. 

Figure 1 illustrates these approaches. 

McLeod' provides an example of the 
first approach. Lorie and Plouffe^ and 
Stonebraker ^ provide examples of the sec¬ 
ond approach. Lori and Plouffe discuss 
the extensions of system R and Stone¬ 
braker reports on the enhancements of IN¬ 


GRES. The third approach is the most 
popular one in industry, because it allows 
the use of off-the-shelf DBMS and the sys¬ 
tem can rapidly be made operational. 
Katz'* provides an example of the fourth 
approach. 

Here we describe a solution based on the 
first approach, because the second ap¬ 
proach requires extensive enhancements 
to the current DBMS, the third approach 
does not meet the flexibility and efficiency 
desired in the CAD environment, and the 
fourth approach ignores capabilities pro¬ 
vided by high-level data models and 
database technology. 

Our solution provides a framework for 
the development of an application- 
oriented DDBMS. It distinguishes the 
refinements, alternatives, and versions 
because they represent different design ac¬ 
tivities. It takes into consideration the 
multistage nature of the design process, 
and the multi-aspect nature of assemblies 
of design objects. It uses an object- 
oriented data model that provides mecha¬ 
nisms to support refinements of assem¬ 
blies of objects at different stages of the 
design. 


The problem 

The objects modeled by engineering and 
design databases are usually assemblies of 
parts that can themselves be composed of 
smaller parts. Such assemblies are called 
composite objects. Objects not assemblies 
are called atomic objects. ^ Composite ob¬ 
jects have a hierarchical structure. The 
leaves of the hierarchy are atomic objects, 
and the internal nodes are composite ob¬ 
jects. The hierarchical structure of an ob¬ 
ject can be described at the type level and 
at the instance level. Figure 2a illustrates 
the hierarchical structure of a four-input 
AND gate as an assembly of a two-input 
AND gate. Figure 2b illustrates the same 
hierarchical structure for a four-input 
AND gate at the instance level. 

Generally, the design of an object starts 
with high-level descriptions of some 
aspects of the object at the type level. Even 
if the object has many instances of another 
object as its parts, the part is described 
only once. Designers complete the de¬ 
scription of the design at the type level, 
step-by-step and by iterative refinements. 
This process creates many refinements of 
the object. A refinement of a description is 
another description that contains at least 
the information in the original descrip¬ 
tion. A refinement of a description of an 
object at the type level is called template 
refinement. A template refinement may 
contain more information about an 
aspect, or may define a new aspect. Figure 
3 illustrates three different aspects of a 
four-input AND gate. 

Figure 4 illustrates a refinement of the 
functional aspect in Figure 3a. This refine¬ 
ment results when the bill-of-material in¬ 
formation of the object is added to its 
functional aspect. 

Two template refinements are indepen¬ 
dent if the information added by one does 
not depend on the information added by 
another. Otherwise they are dependent; 
changes in the information content of one 
refinement will affect the information 
content of the other refinement. Figure 5 
illustrates a refinement of the functional 
aspect in Figure 3a. This refinement is in¬ 
dependent of the refinement in Figure 4 
because one can change the symbolic 
aspect without changing the bill of 
material aspect. 

Figure 6 illustrates a dependent refine¬ 
ment of the refinement in Figure 4 because 
if the bill-of-material changes, then the 
connections among parts will change. 

Two template refinements are called 
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alternatives if the information added by 
one redefines some of the information 
added by the other. The refinement in 
Figures 6 and 7 are alternatives because 
they define the connections among the 
parts of the object in two different ways. 
Alternatives are inconsistent with each 
other in the sense that no correct descrip¬ 
tion of an object can contain the informa¬ 
tion contained in two or more alternatives. 

The descriptions of composite objects 
contain references to the descriptions of 
their parts. Each part may have several 
refinements and alternatives. A reference 
from a composite object to a part is 
generic, because it can be bound to any 
one of the alternatives of the part. Any 
refinement of a part leads to a refinement 
of the composite objects that reference 
that part. The refinements of composite 
objects due to the refinements of their 
parts are called explosion refinements. 
The refinement of a four-input AND gate 
caused by the refinements of a two-input 
AND gate is an example of explosion 
refinements. 

A version of an object is a description of 
that object that contains all the informa¬ 
tion necessary to instantiate the object. 
That is, all the aspects of the object have 
been described, and all the references from 
it have been bound to the versions of its 
parts. A version is a snapshot of the design 
as assembled by the designer at a point in 
time. 

Versions freeze design decisions made 
before the instantiation of the design ob¬ 
ject. Designers can instantiate a version as 
often as they wish. Some design decisions 
can be made only after the Instantiation of 
the version and the running of simulation 
and analysis tools. Designers may there¬ 
fore want to refine the objects at the in¬ 
stance level. This type of refinement is 
called instance refinement. 



Figure 2. Hierarchical structure of a four-input AND gate showing the type level (a) 
and instance level (b). 


OUT=lnlAln2Aln3Aln4 


(a) _(b)_fc) _ 

Figure 3. Three aspects of a four-input AND gate: (a) functionai, (b) logical, and 
(c) symbolic. 



OUT = lnlAln2Aln3Aln4 




OUT= ln1Aln2Aln3Aln4 




Figure 4. A refinement of the functional Figure 5. An independent refinement, 
aspect of a four-input AND gate. 


Template refinements 

Now let us develop an implementation- 
independent model of refinements and 
alternatives of objects at the type level. Let 
A /1 be an increment of information added 
to the description t in order to create a 
refinement /1 = / + A /1 of /. Suppose a 
designer would like to add the increment 
of information A/^ and thus create a new 
refinement. Three cases are possible: 

(1) A /2 depends on A/ 1 . 

In this case the new refinement ti = t + 
Ai I + A /2 is a dependent refinement of t 



Figure 6. A dependent refinement. 



Figure 7. An alternative refinement. 
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(a) (b) 


Figure 8. Two dependent refinements of 
t. ti = t\ + Ai2 = t + All + Ml- 


with respect to the refinement t\, il¬ 
lustrated by Figure 8. 

“Dependent” means that the informa¬ 
tion provided in A12 is semantically depen¬ 
dent on the information provided by Ai 1. 
This relationship implies that if A/'i 
changes, then A/2 should change accord¬ 
ingly. Note that the triangular nodes in 
Figure 8a are not refinements, but in¬ 
crements of information. The diagram in 
this figure is called an incremental refine¬ 
ment graph (IRG) of description t. Each 
increment of information in the IRG is an 
incremental refinement. The nodes in 
Figure 8b represent t and its refinements t j 
and ti. The diagram in this figure is called 
a refinement graph (RG). The edges in the 
IRG and RG represent dependency rela¬ 
tionships. The information in the node at 
the end of an edge is dependent upon the 
information in the node at the beginning 
of that edge. 

The significance of the IRG lies in the 
fact that designers wishing to refine a 
description do not want to repeat the in¬ 
formation in that description. They prefer 
to define new information only. The 
significance of the RG is that the design¬ 
ers’ objective in adding the increment of 
information is to create a description con¬ 
taining all the information about the ob¬ 
ject. 

(2) A/2 is independent of Ai'i and does 
not redefine information in A/1. 

In this case the new refinement ti = t-¥ 
Aij is an independent refinement of t with 
respect to 11. The IRG and RG of this case 
are given by Figure 9a and Figure 9b, 
respectively. The node labeled E(A/i -I- 
Aii) in Figure 9a represents a node with 



of 1 .13 = t + All -I- Ai2. 


no increment of information. This node 
represents the designer’s intention to 
define a new refinement containing the in¬ 
formation contents of t, Aij, and A/^. 
This refinement is labeled 13 in Figure 9b. 

(3) A12 redefines the information in 

All. 

In this case the new refinement ti = t + 
Ail is an alternative refinement of t with 
respect to the refinement 1 1, illustrated by 
Figure 10. 

The difference between Figure 10a and 
Figure 9a lies in their bottom nodes. The 
bottom node in Figure 10a (labeled 
represents inconsistency. In other words, 
I, = t + Ail + Ail contains conflicting 
information and therefore cannot be 
refined further or used in creating versions 
of design objects, while the node ^3 in 
Figure 9a represents consistent informa¬ 
tion and can be refined further or used in 
other operations. 

Derivation of refinements. Designers 
define increments of information (nodes 
in the IRG) and specify the dependency 
relationships (edges in the IRG) among 
the increments. The system will verify the 
designers’ specification and take proper 
action if it discovers any violation of the 
built-in semantics of refinements and al¬ 
ternatives. For example, if a designer 
declares the increment A12 an indepen¬ 
dent incremental refinement of t with 
respect to the increment Ai'i, while Aii 
redefines some of the information in Ai 1, 
the system will inform the user and reject 
the operation. 

There must be a mechanism to derive 
refinements from incremental refine¬ 



fa) (b) 


Figure 10. Two alternative refinements 
of f. !( = t + Ail + ^*2 is a" inconsis¬ 
tent description. 


ments, because incremental refinements 
are only partial descriptions of design ob¬ 
jects. The basis of this mechanism is infor¬ 
mation summation, represented by “ -I-.” 
Information summation is a binary opera¬ 
tion. The operands of information sum¬ 
mation are refinements or incremental 
refinements. The result of an information- 
summation operation contains all the in¬ 
formation contained in the operands of 
the operation if none of the operands 
redefines the information in the other one: 
otherwise, the node !, represents incon¬ 
sistency. 

Figure 11 is an algorithm that takes an 
IRG and derives the corresponding RG. 
The algorithm starts from the root of the 
IRG and applies “ -I- ” along the edges of 
the graph. The resulting RG graph is 
isomorphic to the given IRG graph. Note 
that the algorithm as stated here is destruc¬ 
tive, in the sense that it transforms the IRG 
to RG.* This in-place transformation is 
not necessary and can be avoided in actual 
implementation. 


‘Note that the nodes of the RG represent only those 
refinements that users have found interesting at some 
point in the design process and have therefore specified 
by incremental refinements and their interconnections. 
The set of these refinements denoted by S is a subset of 
R, the set of all possible refinements that can be formed 
by the incremental refinements defined by the designers. 
The set R can be derived by the insertion of the results 
of repeated applications of the operation “ + ” to the 
pairs of elements in the set S, into S itself, until no new 
element can be added. The set R is a complete lattice 
under the approximation ordering,® The meet opera¬ 
tion is the intersection of information; the meet of two 
elements of R is another element of R, which contains 
only the information contained in both of those ele¬ 
ments. The join operation is +. This observation is a 
promising one and should be explored further for 
future expert CAD systems. 
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algorithm sum (root ); 

for each node n which can be reached directly from the root do 
replace o by o + root; 
call sum ( 0 ); 

Figure 11. Derivation of the RG from the IRG. 


The isomorphism between the IRG and 
RG has two important implications: 

(1) Users can define incremental refine¬ 
ments, but can logically think of 
these increments as the refinements 
of design objects. 

(2) The system can store incremental re¬ 
finements, rather than refinements, 
and derive the required refinements 
upon request. 

The algorithm to derive a desired refine¬ 
ment from the information provided in the 
IRG is straightforward: the information 
content of the increments corresponding 
to the specified refinement and all its 
ancestors must be added by the 
information-summation operation. 

An example. The following design ex¬ 
ample illustrates template refinements and 
their dependencies. Let us assume the 
designer wishes to design a four-input 
AND gate and that the original description 
is the functional aspect of the four-input 
AND gate, as shown in Figure 12. The 
designer refines the description in Figure 
12 by providing the bill-of-material (hard¬ 
ware configuration) and a graphical sym¬ 
bol for the four-input AND gate. The IRG 
at this point of design is shown in Figure 
13. Note that A/] and A/^ are independent 
refinements. 

The designer recognizes that he may 


OUT = lnlAln2Aln3Aln4 


connect the two-input AND gates speci¬ 
fied by Ai 1 in two different ways to con¬ 
struct a four-input AND gate. He 
therefore defines the connections of the 
parts by two alternative refinements. The 


Figure 12. Original description of the 
design object. 


IRG of the design object at this point of 
the design is shown in Figure 14. 

The designer continues by refining the 
graphical symbol of the four-input AND 
gate. He creates two alternative graphical 
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Figure 15. Completion of the design at the type level. 


symbols to represent the number of gate 
levels of the new object. A/5 is the sym¬ 
bolic description of the three-level gate 
and A/'e is the symbolic description of the 
two-level gate. At this point the designer 
may decide to put the descriptions of dif¬ 
ferent aspects of the design object together 
to form a complete description of that ob¬ 
ject. To do so he defines two incremental 
refinements, A/7 and A/g, as shown in 
Figure 15. Note that the refinement cor¬ 
responding to A/7 contains all the infor¬ 
mation defined by t, A/|, A/2, A/4, A/5, 
and A/7. The refinement corresponding to 
A/g contains all the information defined 
by /, A/], A/2, A/3, A/g, and A/g. 

Explosion refinements and versions. As 
long as designers deal with atomic objects, 
template refinements are sufficient to 
describe and manage the refinements of 
objects. In the presence of assemblies, 
however, the designer must deal with ex¬ 
plosion refinements, which are the refine¬ 


ments of assemblies caused by the refine¬ 
ments of their parts. 

Designers usually decompose large 
composite objects into parts, design each 
part, and then assemble the parts. Decom¬ 
position allows designers to ignore ex¬ 
plosion refinements temporarily and to 
concentrate on the design of each part. It 
increases the intellectual manageability of 
the design by reducing the size of the 
design. 

Consider the set of refinements and 
alternatives of a composite object. Ele¬ 
ments of this set reference parts that may 
themselves have a set of refinements and 
alternatives. The composite object can 
therefore be assembled in many different 
ways. Moreover, any refinement of a part 
will cause refinement of its parts using that 
part. A designer of a composite object 
may not want his design to change because 
of the refinements of its parts. 

The notion of version provides a mecha¬ 
nism to protect the design of composite 


objects against unwanted changes caused 
by the refinements of their parts. Consider 
the example of the previous section. 
Assume that a designer of a composite ob¬ 
ject (say a decoder) is using four-input 
AND gates. The hierarchical structure of 
this object is shown in Figure 16. Further 
assume that the designer has decided to use 
two-level, four-input AND gates rather 
than three-level, four-input AND gates. 
These assumptions imply that the descrip¬ 
tion of the decoder has a reference to 
template A/g in Figure 15. If the designer 
of a four-input AND gate refines the ob¬ 
ject described by A/g, the design of the 
decoder will be refined. If the designer of 
the decoder does not want this change, he 
can define a version of the two-level, four- 
input AND gate and refer to this version 
from the definition of the decoder. The 
designer of the four-input AND gate can 
still refine his design, but these refine¬ 
ments will not affect the version refer¬ 
enced by the decoder. 
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1 Decoder b 

[type descriptioni 

Inverter | 

type description | 

4-input AND gate || 

type description | 




1 2-Input AND gate b 

1 type description | 


figure 16. Hierarchical structure of the decoder. 


Template Terminal. 

Properties Label, Direction, Position. 
Operations NewTerminal, SetPosition. 


New Terminal ( -Terminal, TERMLBL, TERMDIR ): 

/'Creates a new instance of Terminal*/ 

tS :=New ( -Object, Terminal ); 

Label ( S ): = TERMLBL; 

Direction ( S j: = TERMDIR; 

Position ( S ) : = NewPoint ( -Point, 0,0 ). 


SetPosition ( -TERM, X,Y ): 

/'Moves an instance terminal TERM to Position X, Y */ 
Move( -Positionj TERM ), X,Y ). 


Figure 17. A definition of Terminai in the ODM. 


Instance refinements. After a version is 
created, it is instantiated. The instance is 
then analyzed and validated by the run¬ 
ning of simulation and analysis tools. 
Finally, blueprints and fabrication data 
are created. If an object is used in a com¬ 
posite object n times, it is described only 
once at the type level, but is instantiated n 
times when the composite object is instan¬ 
tiated. These instances have the same 
properties at the type level, but differ at 
the instance level. For example, the prop¬ 
erty Number of Inputs of all two-input 
AND gates has the value 2 and is defined at 
the type level, while the property Position 
of an instance of a two-input AND gate 
differs from that of another instance and is 
specified at the instance level. 

A design object might be refined at the 
instance level in order to specify instance 
properties and to resolve problems dis¬ 
covered by the analysis performed after 
instantiation. For example, components’ 
positions on the printed circuit board may 
be adjusted to allow better layout and 
routing. To support instance refinements, 
the data models of the DDBMS must 
allow certain properties of a design object 
to be specified and modified after the ob¬ 
ject is instantiated. 


ODM and management 
of refinements, alter¬ 
natives, and versions 

An object-oriented data model called 
ODM^ provides a set of coherent facilities 
to support refinements, alternatives, and 
versions of assemblies. ODM integrates 
concepts from functional data models 
(FDM) * and the actor model of computa¬ 
tion. ® The fundamental goal of ODM is to 
provide modeling facilities that allow the 
situations arising in design applications to 
be modeled faithfully and without exces¬ 
sive database design effort, and to provide 
operations to manipulate design data easi¬ 
ly and efficiently. 

Templates and instances. The universe 
of discourse in ODM consists of templates 
and instances. Templates are descriptions 
of entity types. Instances are descriptions 
of entity instances. Each template has a 
unique user-defined identifier. Each in¬ 
stance has a permanent and unique sys¬ 
tem-defined identifier. A template is the 
classification of its instances. Both 
templates and instances are objects. ODM 
objects are convenient aggregations of in¬ 
formation describing the real world ob¬ 


jects. In contrast to entities in other data 
models, objects in ODM are aggregations 
of both active and passive data. 

Any ODM object has a set of properties 
and operations defined as part of the 
template of the object. An ODM object is 
like an abstract data type (ADT)and the 
set of properties and operations of the 
object is like the interface of the ADT. The 
properties of an object at a given time 
determine the state of the object at that 
time. Operations of an object are intended 
for use in changing the state of the object. 
Operations also enforce constraints and 
provide an application-oriented interface 
to the database. 

Figure 17 illustrates a template that 
defines an entity type called Terminal. 
NewTerminal is an operation that upon 
execution creates an instance of Terminal. 
All the instances of Terminal have the 
properties Label, Direction, and Position. 


Template refinements in ODM. In¬ 
cremental refinements are defined as 
templates in ODM. A dependent refine¬ 
ment of a template is defined as its 
subtemplate. A template, therefore, is the 
supertemplate of its refinements. Subtem- 
plates inherit the properties and opera¬ 
tions of their supertemplates. 

Let / be a template and A/ ] be the incre¬ 
ment of information added to t to create a 
refinement /1 = / -i- A/ 1 . In ODM A /1 is 
defined as a subtemplate of t. The in¬ 
heritance and subtemplate/supertemplate 
relationships allow t\ to be defined 
without repetition of the information in t. 
Only the information not in t, Ai ^, needs 
to be defined. The inheritance, therefore, 
is the same as an information-summation 
operation and the supertemplate/subtem¬ 
plate relationships are the same as the 
edges in the IRG. In order to enforce the 
semantics of independent, dependent, and 
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Template And-2, 

Properties tnl, In2, Out, Delay. 

Operations New. 

Delay (And-Z);-to. 

New And-2 ( -And-2. it, 12. 0 ); 

/‘Creates a new instance of 2-input And-gate */ 

tS :=New (-“Surrogate, And-2 ); 

Ini (S)New Terminal ( -Terminal, II, T’ }; 
In2 (S): =5New Terminal ( —Terminal, 12,): 
Out (S): =New Terminal { -Terminal, 0. ’O' ). 


Figure 18. A definition of a two-input AND gate in the ODM. 


alternative refinements through inher¬ 
itance, the following rules are defined: 

(1) No subtemplate can redefine a prop¬ 
erty or an operation of a supertemplate. 
The justification for this rule is that if a 
refinement t j redefines part of the infor¬ 
mation defined by another refinement t, 
then /1 is an alternative refinement of t. 
Therefore, t j will be a subtemplate of the 
supertemplate of t rather than a sub¬ 
template of t itself. 

(2) A subtemplate with more than one 
supertemplate inherits all the properties 
and operations of its supertemplates. If 
the same information is inherited through 
several supertemplates of a subtemplate, 
then that information is inherited by the 
subtemplate only once. The need for sub¬ 
templates with more than one supertem¬ 
plate arises from the semantics of indepen¬ 
dent refinements. 

(3) No more than one supertemplate of 
a subtemplate can define the same infor¬ 
mation. The need for this rule arises from 
the semantics of alternative refinements. 
If two supertemplates of a subtemplate 
define the same information, they are 
alternatives and their common subtem¬ 
plate is an inconsistent refinement. 

Explosion refinements in ODM. A data 
model intended for engineering applica¬ 
tions must support properties that de¬ 
scribe the assembly structure of composite 
objects. To allow designers to specify these 
properties when they define a template 
rather than every time a new instance is 
needed, a special operation called creation 
is defined as part of the template. 


The creation operation is the main 
mechanism in ODM for defining 
assemblies of parts and supporting explo¬ 
sion refinements. Creation of a composite 
object has references to the templates 
describing its parts. These references are 
generic in the sense that they can be bound 
to any alternative of the part. Because of 
these generic references, modifications of 
a part automatically cause the modifica¬ 
tions of composite objects that reference 
that part. 

When a composite object is instan¬ 
tiated, its parts must be instantiated. Since 
any one of the parts can itself be a com¬ 
posite object, the creation of parts may 
cascade at many levels and in several direc¬ 
tions. The creation operation, therefore, 
automates the process of instantiation and 
frees users from the responsibility of main¬ 
taining referential integrity among the ob¬ 
jects. It ensures that all the instances of 
parts used in the instance of the assembly 
exist. 

Figure 18 illustrates a template that 
defines a two-input AND gate. The crea¬ 
tion operation of this template, called 
NewAnd-2, invokes NewTerminal, which 
is the creation operation of the template 
Terminal in Figure 17. For each instance of 
And-2, three instances of Terminal are 
created automatically. 

Instance refinements in ODM. The 

values of some properties do not change 
from one instance to another. Although all 
the instances of the template inherit these 
properties, they need to be specified and 
stored only once with the template. These 
properties are called type properties. Note 
that the binding time of values of these 
properties is template definition time. The 


delay property of And-2 in Figure 18 is an 
example of a type property. 

Some properties have different values 
for different instances of the template. 
That is, their values change from one in¬ 
stance to another. The values of these prop¬ 
erties are specified at the instance’s crea¬ 
tion time and are stored with the instance’s 
information. These properties are called 
instance properties. The values of instance 
properties of objects may not be changed 
after the objects are created. Label and 
Direction of Terminal in Figure 17 are ex¬ 
amples of instance properties. The values 
of these properties are passed as parame¬ 
ters of the creation operation when the in¬ 
stances are created. 

Template definitions and type proper¬ 
ties represent the design decisions made at 
the early stages of the design. Instance 
properties represent design decisions made 
at the instance’s creation time. 

However, some design decisions can be 
made only after the instantiation of the 
design and the running of simulations and 
analysis tools. Therefore, some properties 
are bound to their values after instances 
are created. These properties are called 
dynamic properties. The Position of Ter¬ 
minal in Figure 17 is an example of a 
dynamic property. 

The type properties of a template can be 
changed only by modification of the 
template. Modification of a template leads 
to another template that is an alternative 
of the original template. The instance prop¬ 
erties can be changed by creating a new in¬ 
stance. Existing instances remain un¬ 
changed. The dynamic properties of an in¬ 
stance can be changed without modifica¬ 
tion of the template or creation of a new 
instance. 

Dynamic properties and operations are 
the main mechanisms of ODM that sup¬ 
port instance refinements. The instance 
refinement is the simplest type of refine¬ 
ment (from the database management 
point of view) because it does not create a 
new object: it only changes the state of the 
object. ODM does not maintain multiple 
alternatives of an instance object because 
dynamic properties are intended to model 
detailed and changing design decisions. 
Maintaining the instance alternatives of 
the design is costly and will not serve any 
useful purpose. Operations are provided 
that allow designers to change these prop¬ 
erties back and forth for fine tuning of the 
design. The operation SetPosition of Ter¬ 
minal in Figure 17 can change the Position 
of an instance terminal. 
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CAD database 
architecture and 
creation of consistent 
versions 

Let us now integrate ODM and the 
model of refinements, alternatives, and 
versions into a design DBMS environment. 
We will briefly review the distinguishing 
characteristics of CAD application en¬ 
vironments, propose an architecture for 
design databases, and describe the cre¬ 
ation of consistent versions of design 
objects. 

Characteristics of CAD appiication en¬ 
vironments. Design is the work of a team. 
Each member of the team may begin a 
transaction that involves a large volume of 
data and persists for long time. Conse¬ 
quently, transactions in design applica¬ 
tions cannot be considered the unit of 
recovery because a significant amount of 
work may be rolled back in case of a 
failure. 

Some transactions, such as editing a 
layout on the graphics terminal, consist of 
short interactive operations. Some others, 
such as running a simulation, consist of 
execution of long and complicated algo¬ 
rithms in batch mode. Interactive opera¬ 
tions require user-friendly interfaces; the 
batch operations require programming 
language interfaces with efficient support 
for common data structures. 

Conventional DBMSs avoid the in¬ 
terference among transactions sharing the 
same data by locking and time-stamping. 
Because of the volume of data involved in 
design transactions, and the duration of 
these transactions, conventional locking 
and time-stamping techniques cannot be 
used for concurrency control. 

In addition to conventional constraints, 
such as referential and domain con¬ 
straints, design applications must satisfy 
another group of constraints called design 
rules. Checking the design rules usually in¬ 
volves a considerable amount of data and 
computation. In contrast to conventional 
constraints, which can be enforced auto¬ 
matically by the DBMS, design rules are 
usually checked by design tools and can¬ 
not be enforced automatically. 

In conventional DBMSs, the life of an 
object begins when it is inserted into the 
database and terminates when it is re¬ 
moved from the database. Design applica¬ 
tions also deal with objects that live longer 
than the permanent objects of the data¬ 
base because they survive the design proj¬ 
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Figure 19. Design database architecture. 


Table 1. Cbaracteristics of Parts, Project, and Private DBs. 


Parts DB 

Project DB 

Private DB 
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High ievei 

Simple 

High level 

Data retrievai 
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Simple 

High level 

Update 

Simpie 
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Conventional 

Concurrency 
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Sophisticated 

Single user 

Recovery 
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Sophisticated 

Conventional 

Security 

Conventional 

Sophisticated 

Conventional 

integrity 

Simple 

Sophisticated 

Sophisticated 

PL interface 

Simple 

Simple 

Efficient 


ect. These objects represent common 
primitive components available to more 
than one design database. 

Data sharing in design applications has 
special peculiarities. The data describing 
common primitive components are shared 
by the databases of several design projects. 
The data in a design project are shared by 
the members of the design team. The data 
manipulated by one designer cannot be 
used by another designer. 

Proposed design database architecture. 
To support this wide range of capabilities, 
we propose the following design database 
architecture. The architecture consists of 
three types of databases, called Parts DB, 
Project DB, and Private DB, illustrated in 
Figure 19. 

The underlying idea of this architecture 
is simple. Design databases contain data 
that have different characteristics and are 
used in different ways. Some are shared, 
some are not; some must be guaranteed 
consistent, others cannot always be consis¬ 
tent; some are permanent, and some are 
temporary. The objective is to reduce the 
overhead of managing design data by 
grouping together data with similar 
management requirements and storing 
each group in a database with appropriate 
facilities. 

The characteristics of each database are 
summarized in Table 1. 


A Parts DB contains components 
usable in current and future designs. These 
components are immutable objects. Addi¬ 
tion of a new component to a Parts DB is a 
privileged operation. 

A Parts DB is shared by Project DBs, 
which maintain refinements, alternatives, 
and versions. There exists one Project DB 
for each design project. The objects taken 
from a Parts DB and the objects defined in 
a Project DB form an evolving repository 
of components for the project. Designers 
and tools working on the same design 
project share a Project DB. 

Designers check the data out of a Proj¬ 
ect DB into their Private DB and check 
them back in after modifications. Lengthy 
constraint checking and validation opera¬ 
tions are performed when the data are 
checked back into the Project DB. Private 
DBs are logical images of design work¬ 
stations, which are smaller and simpler 
machines connected to a larger and more 
powerful host computer. The Project DBs 
and the Part DB are maintained in the host 
machine. Each designer uses the Project 
DB through a Private DB. In this sense 
Private DBs are the users’ interface with 
the Project DB. 

Creation of consistent versions. The 
process of design starts with descriptions 
of some aspects of the design object. 
Designers check out from the Project DB 
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into their own private DBs the refinements 
they wish to work on. The check-out is the 
beginning of a long transaction for a 
Private DB. Designers perform retrieval 
and update operations on the refinements 
in the Private DB in order to create a local¬ 
ly consistent description of an aspect of 
the design. Local consistency means that 
the description does not violate any built- 
in or user-defined constraint applicable to 
that description, without regard to its rela¬ 
tionships with other descriptions. 

The newly created locally consistent 
description is checked back into the Proj¬ 
ect DB as a new refinement or alternative. 
The check-in operation, which terminates 
the long transaction started by the cor¬ 
responding check-out operation, will take 
place successfully if the consistency of the 
project DB can be ensured. This type of 
consistency is called global consistency 
because it concerns the consistency among 
locally consistent descriptions. The check¬ 
in operation may require lengthy valida¬ 
tions in order to ensure global consistency. 

The objective of the designer in per¬ 
forming repeated check-out and check-in 
operations is to create a consistent version 
of the design object. A version of a design 
object is a refinement that contains the 
description of all the aspects of the object, 
that is globally consistent, and that refer¬ 
ences only the already defined versions of 
parts. 

Designers may specify some of the alter¬ 
native refinements as default alternatives. 
This specification means that if the system 
is asked to bound the references automati¬ 
cally, it will select the default alternative. 
Some alternatives might be inactive. These 
refinements have been shown to have little 
value to designers. Alternatives pursued 
by designers are active alternatives. 

W e have distinguished three types 
of refinements: 

(1) template refinements, refinements 
of objects at the type level; 

(2) explosion refinements, the refine¬ 
ments of assemblies caused by the 
refinements of their parts; and 

(3) instance refinements, refinements of 
objects at the instance level. 

Our primary conclusion is that refine¬ 
ments, alternatives, and versions of com¬ 
posite objects can be supported by hier¬ 
archies of supertemplates/subtemplates 
(which are generalization hierarchies*’’*^) 
and by appropriate inheritance rules. Our 
main contribution here is a framework for 
achieving effective management of refine¬ 


ments, alternatives, and versions of com¬ 
posite objects in CAD applications. 
Future work based on this research should 
concentrate on the implementation of the 
ODM in such a way as to support the 
model of refinements, alternatives, and 
versions. 
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BOOK REVIEWS 


Readings in Medical 
Artificial Intelligence: 
The First Decade 

William J. Clancey and Edward H. 
Shortliffe, eds. (Addison-Wesley 
Publ. Co. Reading, Mass., 1984, 

512 pp., $39.95) 

This book is an exhaustive review of 
the use of artificial intelligence in 
medicine, or AIM, during the period 
1971-1981. 

This brings together 19 articles, con¬ 
sidered by the editors to be among the 
best and most influential work in the 
field, and is meant to serve not only as a 
textbook for those not familiar with 
AIM but also as a reference work for 
those who are. 

The book begins with an introduction 
in which the editors provide a brief 
history of the subject, define knowledge- 
based programming, present criteria for 
characterizing and comparing AIM pro¬ 
grams, and outline the state of the art in 
the field. Each chapter (which includes 
an article, except the first and the last) is 
prefaced with a brief introduction with 
the editors’ view of the author’s con¬ 
tribution to the field, the reason the arti¬ 
cle was selected, an overview of its con¬ 
tent, a discussion of how the subject of 
the article evolved after the article ap¬ 
peared, and how the subject relates to 
other chapters in the book. 

The second chapter, by Gorry (one of 
the pioneers in the field), presents the 
beginning use of AI approaches to 
medical problem solving. This is fol¬ 
lowed by a survey article (1979) of 
computer-based clinical decision aids. 
The authors, Shortliffe, Buchanan, and 
Feigenbaum, describe the evolution of 


computer-based approaches to medical 
advice giving, focussing on the limita¬ 
tions of early work generated by the use 
of traditiond models. There is need for 
knowledge-engineering techniques to im¬ 
prove performance and acceptance of 
AIM systems is one of the conclusions 
of the authors. 

In the fourth chapter Kulikowski gives 
quite a different presentation of the 
knowledge-based perspective. In his in¬ 
troduction he gives an overview of the 
early AIM systems. Classic systems, 
placed in the context of the expert 
systems subarea of AI, are described in 
the next four chapters: MYCIN (known 
for its use of rules), PIP (use of frames), 
CASNET (use of a causal-associational 
network), and INTERNIST (handling of 
multiple problems). The following 
chapter by Szolovitz and Pauker makes 
detailed comparisons of the above four 
systems, summarizing and integrating 
them. Two interesting AIM systems 
developed from MYCIN program are 
presented in the next two chapters: 
Fagan’s VM (Ventilator Manager), im¬ 
portant for gaining insights into tempor¬ 
al reasoning, and Clancey’s GUIDON, 
important for understanding intelligent 
computer-aided instruction. 

The editors have made a good selec¬ 
tion, including Feltovich’s psychological 
study about representations issues in 
modeling physicians’ reasoning. This 
chapter is important to AIM researchers 
because of the kinds of questions asked 
and the form the model of reasoning 
takes. The same problem of knowledge 
representation is treated in the following 
two chapters. In the first, Gomez and 
Chandrasekaran adopt an analytical 
view for studying the nature of medical 
knowledge, applying it in implementa¬ 
tion of a prototype diagnosis system of 
liver disease, named MDX. The second. 


Recently published books and new periodicals may be submitted for 
review to the book reviews editor: 

Francis P. Mathur, Mathematics Department, California State Polytechnic 
University, 3801 West Temple Avenue, Pomona, CA 91768, (714) 598-4421. 

Note: Publications reviewed in this section are not available from the 
IEEE Computer Society; they must be ordered directly from the publisher. 


by Patil, Szolovitz, and Schwartz, pre¬ 
sents the state of the art in medical 
knowledge representation, i.e., the prin¬ 
cipled representation. This is made in 
the context of ABEL (Acid-Base and 
ELectrolyte) program. Clancey’s 
NEOMYCYN system (for application to 
teaching) and Swartout’s XPLAIN sys¬ 
tem are the subjects of the following two 
chapters. The significance of these two 
systems lies in their growing explanatory 
capability. 

The next two chapters are dedicated 
to the systems oriented toward knowl¬ 
edge acquisition. Both of the two sys¬ 
tems presented implement knowledge 
acquisition in the form of partially auto¬ 
mated learning. These systems are: 
Blum’s RX system (based on statistical 
analysis of a database) and the SEEK 
system of Politakis and Weiss (based on 
the analysis of cases). While all the pre¬ 
ceding presented systems are experimen¬ 
tal, the last two systems described in this 
book are of practical importance. These 
systems are: PUFF (an expert system 
that interprets pulmonary function 
tests), implemented in Basic language 
and running on a PDP-11 computer 
routinely used by physicians from the 
pulmonary physiology lab of Pacific 
Medical Center; and EXPERT/Electro- 
phoresis (an expert system running on a 
microprocessor), being the first mar¬ 
keted medical device in the development 
of which AI techniques were used. 

The editors’ views of the future of 
AIM research, with emphasis on the 
challenges as well as the promise that lies 
ahead, are the subject of the closing 
chapter. The volume is provided with a 
rich bibliography (over 450 references), a 
subject index, and a name index—very 
useful tools for consulting the book. 
Contributors are also presented at the 
beginning of the book. 

This book fulfills the editors’ double 
intention, that of presenting the articles 
(from a historical perspective) in the 
order of conceptu^ development of the 
AIM field and that of assessing the 
significant barriers that remain to be 
overcome before the widespread clinical 
use of AIM will be achieved. 

Gh. Curelet-Balan 

Research Institute for Computers 

Official Postal PTTR-30, (PR) 

Bucharest, Romania 
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“Any clod can have the facts, 
but having opinions is an art.” 

Charles McCabe 
San Francisco Chronicle 


smo 


Artificial intelligence: Fact or fiction? 


We hear much these days about artifi¬ 
cial intelligence. The expression suggests 
intelligence, artificially created. Is this 
indeed so? Are we on the verge of 
creating machines that will exhibit 
behavior that rivals human intelligence? 

The expression “artificial intelligence” 
dates back to the mid-1950’s, when com¬ 
puters were relatively new and the 
general public was still astounded that a 
machine could carry out thousands of 
multiplications of 10-digit numbers in a 
second. Slightly earlier, in 1949, a book 
titled Giant Brains (E.C. Berkeley, John 
Wiley and Sons, 1949) had described the 
new electronic computers being 
developed. 

People have since time immemorial 
been fascinated by the idea that man 
might be able to create a machine that 
would have the mental capabilities of a 
human. The idea of the robot is part of 
this fascination, as have been many 
aspects of witchcraft and sorcery. 

The question of what constitutes intel¬ 
ligent behavior in humans or machines 
has been (and will continue to be) a sub¬ 
ject for debate. I tell my students that 
artificial intelligence is a property that a 
machine has if it astounds you. Clocks 
were deemed “intelligent” in the middle 
ages, just because it was so astounding to 
have something made of metal and wood 
that could indicate the time of day. 
Locomotives were thought to be 
“devils,” alive and intelligent, by 
peasants in the late 1700’s when, with 
much noise, fire, and puffing smoke, 
they raced through the countryside at 
speeds no human had ever traveled. 

In the same manner, the computers of 


the late 1940’s astonished the public with 
their capabilities to perform high-speed 
arithmetic. However, within 10 years, 
computers had become commonplace, 
astonishment waned, and the public 
started to accept them as routine devel¬ 
opments of our technological age. But 
then computers were applied to solving 
problems that no one had thought possi¬ 
ble for a machine. An early such accom¬ 
plishment was the use of a computer to 
play checkers against a human and, in 
time, to become a better “player” than 
the person who had programmed it. To¬ 
day checker- or chess-playing computer 
programs evoke only yawns; in the late 
1950’s they were astounding, and they 
propelled the idea that the era of man¬ 
made (i.e., “artificial”) intelligence had 
finally arrived. 

It is certainly true that computers to¬ 
day can perform many tasks that could 
previously be performed only by in¬ 
telligent humans. Whether this con¬ 
stitutes intelligent behavior (and exactly 
what is intelligent behavior?) is a philo¬ 
sophical argument that is irrelevant to 
putting computers to productive use. 
Every discipline has a few protagonists 
who will make claims for its capabilities, 
benefits, and virtues that push the 
public’s expectations beyond what can 
be delivered in the foreseeable future. 
Some of them follow what they believe is 
simply the American tradition of good 
salesmanship; others are carried away by 
their own exuberance. A few are true 
prophets who will be vindicated in years 
to come, and a few have succumbed to 
what one might call the “sorcerer syn¬ 
drome.” 


Let us strip the term “artificial intelli¬ 
gence” of its anthropomorphic aura and 
its more extravagant claims, and use it 
simply as denoting “advanced use of 
computers.” I personnally prefer the 
term “machine intelligence.” It 
somehow evokes less emotionalism in the 
lay public. However, “artificial in¬ 
telligence” has now become so widely 
used that, for better or worse, the term is 
going to be with us for a long time. In 
the past the practitioners of AI (as it is 
commonly abbreviated, both by those 
who prefer brevity as well as by those 
who are embarrassed by its implied ar¬ 
rogance) have dealt with such problems 
as machine translation of natural 
language, machine playing of checkers, 
chess, jigsaw puzzles, and similar games, 
proving theorems in mathematics, and, 
most recently, with so-called “expert 
systems” and “knowledge-based 
systems.” (As should be apparent by 
now, workers in this field have a pen¬ 
chant for choosing provocative and 
media-seductive names.) 

The expression “expert system” (or 
“knowledge-based system”) was in¬ 
troduced to describe computer software 
that embodies a collection of knowledge, 
facts, and rules that is similar to what a 
human might employ to solve a par¬ 
ticular problem. There are many prob¬ 
lems that humans solve very well. The 
knowledge may be explicit, that is, avail¬ 
able in written or otherwise readily com¬ 
municable form, or it may be implicit, 
available only in the form of experience 
in certain individuals. It is this latter type 
of knowledge that expert systems strive 
to capture. Thus, there are physicians 
who are expert at diagnosing certain 
cardio-pulmonary illnesses. Some of the 
knowledge used by them is available in 
textbooks, but much is also derived from 
many years of seeing patients with 
diverse symptoms, making diagnoses, 
and later having these diagnoses con¬ 
firmed or refuted (possibly by autop¬ 
sies!). The objective in designing an 
expert system is to capture such experien¬ 
tial knowledge, if possible from many 
different individuals, and embody it in a 
set of facts or rules that then permit the 
system to act in an “expert” manner. 

The goal is not far-fetched; on a modest 
scale some very successful expert systems 
have been designed and placed in opera¬ 
tion. Some of these have been developed 
for medical diagnosis (in certain highly 
limited medical-problem areas), for the 
interpretation of seismic data for oil ex¬ 
ploration, for diagnosing diesel-engine 
malfunctions, and for automatic place¬ 
ment of names on geographic maps. 

If we see Al merely as the advanced 
use of computers, then it means that 


The Open Channel is exactly what the name implies: a forum for the free ex¬ 
change of technical ideas. Try to hold your contribution to one page maximum 
in the final magazine format (about 1000 words). 

We’ll accept anything (short of libel or obscenity) so long as it’s submitted by 
a member of the Computer Society. If it’s really bizarre we may require you to 
get another member to cosponsor your item. 

Send everything to Jim Haynes, Computer Center, UC Santa Cruz, CA 95065. 
Bitnet: haynes® ucscc; Arpa: ucscclhaynes@ucbvax.berkeley.edu. 
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those working in this field are simply 
working at the frontier of computer 
technology, striving to find new and 
more astounding applications, as com¬ 
puters continue to grow in capability and 
as the methodology for programming 
them becomes ever more sophisticated. 

Herbert Freeman 
Rutgers University 
New Brunswick, N.J. 


Final report of ANSI 
Committee LY-2299-BS 

The committee respectfully submits its 
final report, which includes the proposed 
ANSI Standard Mendacity Scale. The 
chairman wishes to commend the com¬ 
mittee members for their hard work, 
patience, and judicious temperments. 

Proposed ANSI Standard 
Mendacity Scale 

Class I Lies 
Class II Damn Lies 
Class III Statistics 
Class IV Damn Statistics 
Class V Benchmarks 
Class VI Delivery promises 
Class VII Campaign promises 

The committee felt it desirable to in¬ 
clude the following explanatory notes: 

(1) Class IV lies are distinguished from 
Class III lies by the willful abuse of 
statistical practice. For example, “Brand 
A lasts up to twice as long as the average 
of five leading brands.” This example 
compares the one best sample of Brand 
A with an average—trying to give the 
impression of superiority when a com¬ 
parison of the average of Brand A and 
the rest may have demonstrated inferi¬ 
ority. A second example is “Brand A 
lasts longer—30.3 months compared 
with 30.2 months for the competition.” 
This example ignores the principle of 
statistical significance. 

(2) Class VII lies are distinguished 
from Class VI lies by the fact that nearly 
every delivery promise is eventually 
followed by delivery. 

William E. Drissel, Chairman* 
CyberScribe Associates 
Grand Prairie, Texas 

•I’ve embellished the original scale but 
have, unfortunately, forgotten its source. 
If anyone can find the original reference, 
please send it to me so that the author 
can be suitably remembered in the 
standard. 
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UPDATE 


Nomination of CS members to IEEE fellow grade sought 


Dear Computer Society members: 

The election to IEEE fellow grade is a 
distinct honor to an individual that is 
conferred as a recognition for outstand¬ 
ing contributions to the profession. The 
fellow grade is the highest grade of 
membership and is the only grade for 
which members cannot apply, but must 
be nominated by another member. 

In recent years the Computer Society 
has been able to increase the number of 
its members elected to fellow grade, but 
the percentages are still well below the 
Computer Society’s proportion of mem¬ 
bers in the IEEE. Thus, as chairman of 
the lEEE-CS Fellows Committee, I urge 


The Nominations Committee of the 
Computer Society of the IEEE invites 
suggestions for Computer Society of¬ 
ficers and Board of Governors nominees 
to serve terms starting on January 1, 

1988. One-year terms for president, 
president-elect, first vice president, and 
second vice president and two-year terms 
for 10 Board of Governors seats will be 
filled by membership election. 

Suggestions for nominees must be re¬ 
ceived by March 25, 1987, and be ac¬ 
companied by biographicEd information, 
which should include any past or present 
participation in the society’s activities by 
the nominee. 

Members are requested to send sugges¬ 
tions to the chair of the Nominations 
Committee, Martha Sloan, Dept, of 
Electrical Engineering, Michigan 
Technological University, Houghton, MI 
49931. 

The following timetable for nomina¬ 
tions and elections (for events following 
the committee’s March 25 nominations 
deadline) was approved by the Board of 
Governors at its November 7, 1986, 
meeting: 

April 10—Nominations Committee 
mails its report to the Board of Gover¬ 
nors; nominees are asked to submit their 
biographies to the Nominations Commit¬ 
tee chair. 


you to nominate qualified Computer 
Society candidates for election to fellow 
grade. There is no doubt that we have 
many deserving members. It is up to our 
members, whether they are fellows or 
not, to take on the task of identifying 
worthy candidates, completing the neces¬ 
sary paperwork, and meeting the dead¬ 
lines for submission of the fellows nomi¬ 
nation to the IEEE. A strict deadline of 
April 30, 1987, is imposed to have all 
nomination forms (B-27, B-3, and B-29) 
in to the IEEE. Early preparation is 
recommended as time is required to 
carefully prepare these documents and 
round up necessary references. Nomina¬ 
tion forms are available either from 


April 28—Final day for receipt of peti¬ 
tion candidates’ names and biographies 
from Board of Governors members by 
the secretary of the society. It is possible 
to mail a clearly identified petition to the 
society office in Washington, DC, or 
directly to the secretary, Duncan H. 
Lawrie, at the West Coast Office, 10662 
Los Vaqueros Circle, Los Alamltos, CA 
90720. 

May 8—Candidates selected at Board 
of Governors meeting. 

June issue of Computer lists the can¬ 
didates selected by the board and calls 
for additional petition candidates from 
the membership. 

June 8—Photos, biographies, and 
position statements of the candidates 
selected by the Board of Governors are 
due at the society’s office in Los 
Alamitos. 

June 22—Petitions with candidates’ 
photos, biographies, and position state¬ 
ments due in Los Alamitos. 

August issue of Computer carries the 
position statements, biographies, and 
photos of the candidates. 

August 3—Ballots are mailed. 

September 15—Last day for receipt of 
marked ballots. 

November issue of Computer lists the 
results of the election. 


Delores Wright at IEEE Headquarters, 
345 East 47th Street, New York, NY 
10017; or from Mercy Kowalczyk, 1730 
Massachusetts Ave., N.W., Washington, 
DC 20036-1903. 

On behalf of the Computer Society 
and the lEEE-CS Fellows Committee, I 
urge you all to consider who might be 
nominated for IEEE fellow. Let’s make 
this a banner year! 

Raymond E. Miller 

Chairman, CS Fellows Committee 


Computer Society nominations are be¬ 
ing solicited by the Fellows Committee, 
chaired this year by Raymond E. Miller, 
Georgia Institute of Technology, School 
of Information and Computer Science, 
Atlanta, GA 30332-0280; (404) 894-3154. 
Miller is available to give advice on 
preparation of the forms, which are 
available from either IEEE Headquarters 
or the Computer Society’s East Coast 
Office (addresses given above). The 
deadline for submitting the forms to the 
IEEE Headquarters Office is April 30, 
1987. 

In evaluating the nominations, the 
IEEE Fellows Committee considers the 
following criteria: 

• individual contributions as engi¬ 
neer/scientist/originator, technical 
leader, or educator; 

• evaluation by an IEEE society; 

• tangible and verifiable evidence of 
technical accomplishment such as 
technical publications, patents, 
reports, or published descriptions or 
products, facilities, and/or services 
performed; 

• confidential opinions of fellow 
references who personally know of 
the candidate’s work (where possi¬ 
ble, these should be associated with 
other than the candidate’s own 
organization); 

• service to IEEE (and AIEE and 
IRE); and 

• total years in the profession. 

Eligibility requirements also include 

five years’ membership and status as 
senior member, which is awarded on the 
basis of an application prepared by the 
member. Application forms are likewise 
available from the IEEE and Computer 
Society headquarters. 


Computer Society calls for nominees 
and issues election timetable 
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CS members elected to IEEE fellow grade 


The IEEE Fellows Committee 
conferred the title of fellow on the 35 
Computer Society members listed below. 
The title recognizes the outstanding 
contributions made by senior IEEE 
members in one or more of the following 


fields: electrical engineering, electronics, 
computer engineering and computer 
science, and the allied branches of engi¬ 
neering and related arts and sciences. 
(Information in parentheses indicates the 
evaluating society, group, or council.) 


Ramesh C. Agarwal, Yorktown Heights, New 
York, for contributions to digital signal pro¬ 
cessing. (Acoustic, Speech, and Signal Pro¬ 
cessing) 

Dharma P. Agrawal, Raleigh, North 
Carolina, for contributions to parallel system 
architecture, interconnection networks, and 
computer arithmetic. (Computer) 

Maier L. Blostein, Montreal, Canada, for 
leadership in developing university/industry 
interaction. (Circuits and Systems) 

Wushow Chou, Raleigh, North Carolina, for 
contributions to the theory and practice of 
large-scale data network modeling and design. 
(Communications) 

Alain Croisier, Paris, France, for leadership 
in digital communications technology and in¬ 
novation in digital filter design. (Communica- 

Bruce R. DeMaeyer, Schaumburg, Illinois, 
for leadership in and contributions to im¬ 
plementing major metropolitan electronic 
switching systems. (Communications) 

Dan E. Dudgeon, Acton, Massachusetts, for 
contributions to multidimensional digital 
signal processing. (Acoustics, Speech, and 
Signal Processing) 

Charles A. Eldon, Palo Alto, California, for 
contributions to the manufacture of high- 
quality electronic components and systems. 
(Components, Hybrids, and Manufacturing 
Technology) 

Domenico Ferrari, Berkeley, California, for 
contributions to computer systems perfor¬ 
mance evaluation and improvement tech¬ 
niques. (Computer) 

Karl E. Ganzhom, Sindelfingen, West Ger¬ 
many, for leadership in the development of 
data processing and the foundation of com¬ 
puter science in Germany. (Computer) 


Edward J. Glenner, Phoenix, Arizona, for 
contributions to the digitization of the US 
public telephone network. (Communications) 

Satoshi Goto, Sagamihara, Japan, for con¬ 
tributions to new directions on VLSI CAD 
research. (Circuits and Systems) 

John R. Hauser, Raleigh, North Carolina, for 
contributions to the understanding of carrier 
transport in semiconductors and to the devel¬ 
opment of cascade solar cells. (Electron 
Devices) 

Munro K. Haynes, Tucson, Arizona, for con¬ 
tributions to the development of magnetic 
core memories and of magnetic recording sys¬ 
tems. (Magnetics) 

William R. Heller, Poughkeepsie, New York, 
for contributions to wiring and packaging of 
digital logic. (Computer) 

John E. Hopcroft, Ithaca, New York, for 
contributions to the field of computing. 
(Computer) 

William J. Judge, Ashburn, Virginia, for con¬ 
tributions to the synthesis and development of 
antijam communications systems. (Aerospace 
and Electronics Systems) 

Glenn F. Knoll, Ann Arbor, Michigan, for 
contributions to nuclear engineering educa¬ 
tion, and for fundamental work in nuclear 
measurements and instrumentation. (Nuclear 
and Plasma Sciences) 

William R. Krnesi, Fairfield, Connecticut, for 
leadership in coordinating electrical and elec¬ 
tronic standardization programs. (Industry 
Applications) 

Victor B. Lawrence, Holmdel, New Jersey, 
for contributions to the understanding of 
quantization effects in digital signal pro¬ 
cessors and the applications of digital signal 
processing to data communications. (Circuits 
and Systems) 


Philip V. Lopresti, Princeton, New Jersey, for 
contributions to the computer-aided manufac¬ 
ture of linear monolithic and hybrid inte¬ 
grated circuits. (Circuits and Systems) 

John D. Musa, Morristown, New Jersey, for 
contributions to software engineering, in par¬ 
ticular software reliability. (Computer) 

Maurice Papo, Nice, France, for leadership in 
computer and communication applications. 
(Computer) 

Stephen S. Rappaport, Stony Brook, New 
York, for developing techniques for multiple- 
access communications and the acquisition of 
spread-spectrum signals. (Communications) 

Sudhakar M. Reddy, Iowa City, Iowa, for 
contributions to the design of testable digital 
logic circuits and fault-tolerant computing. 
(Computer) 

Izhak Rubin, Los Angeles, California, for 
contributions to the analysis and design of 
computer communication systems and net¬ 
works, and to engineering education. (Com¬ 
munications) 

Andre T. Salama, Toronto, Canada, for con¬ 
tributions to the development of power 
semiconductor devices and the design of in¬ 
tegrated circuits. (Electron Devices) 

Alfred W. Scheide, Cincinnati, Ohio, for con¬ 
tributions to the design, development, and ap¬ 
plications of robotics and industrial lasers. 
(Industry Applications) 

Adolf J. Schwab, Karlsruhe, West Germany, 
for contributions to the analysis and design of 
high-voltage and high-current measuring 
devices. (Power Engineering) 

K. Sam Shanmugan, Lawrence, Kansas, for 
contributions to the field of computer-aided 
modeling, analysis, and simulation of com¬ 
munication systems. (Communications) 

Sidney Shapiro, Rochester, New York, for ex¬ 
perimental confirmation of the ac Josephson 
effect and other contributions to the devel¬ 
opment of superconducting tunneling devices. 
(Electron Devices) 

Harold S. Stone, Chappaqua, New York, for 
contributions to parallel and distributed com¬ 
puting, and computer education. (Computer) 

Jimmie R. Suttle, Durham, North Carolina, 
for contributions to the planning and man¬ 
agement of programs of academic research in 
electronics and associated disciplines. (Educa- 

Jose F. Valdez C., Lima, Peru, for creating 
and developing engineering institutions and 
encouraging engineering education. (Engi¬ 
neering Management) 

Robert W. Waynant, Laurel, Maryland, for 
contributions to the demonstration and devel¬ 
opment of vacuum ultraviolet and excimer 
lasers and for the discovery of the H2 
vacuum ultraviolet laser. (Lasers and Electro¬ 
optics) 


Roy Russo resumes presidency 


This January, Roy Russo returned 
to an active role as president of the 
Computer Society of the IEEE. He 
had been on medical leave for several 
months, but is now reported as 
recovered and back at work. 

During Russo’s absence, Tom Cain 


served as acting president. In turn, 
Duncan Lawrie filled in for Cain as 
acting VP of publications. In his 
return announcement, Russo thanked 
Cain, Lawrie, and all Computer Socie¬ 
ty volunteers and staff for their ex¬ 
cellent performance throughout 1986. 
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NEW PRODUCTS 


Software family links Macintosh and DEC VAX 


White Pine Software has announced a 
family of software products to link the 
Apple Macintosh and DEC VAX com¬ 
puters. The products are called VMacs, 
Mac240, and Reggie. 


Convergent Technologies has an¬ 
nounced the Series 386 NGEN worksta¬ 
tion, based on the Intel 80386 micropro¬ 
cessor. The company offers two models, 
the CP-003 and the CP-003/287. The 
CP-003 includes a 16-MHz Intel 80386 
processor; the CP-003/287 includes a 
16-MHz Intel 80386 processor with a 
10-MHz 80287 math coprocessor. 

The models feature memory manage¬ 
ment with a protected mode and virtual 
addressing capabilities; IM byte of RAM 
with parity error detection; a video con¬ 
troller; I/O support for two RS-232-C 
ports, a parallel printer port, and RS-422 
operations; Visinostics software for 
visual diagnostics; and optional memory 
expansion cartridges. 

The CTOS II operating system in¬ 
cludes Cluster software. Convergent’s 
local area network. CTOS II features vir- 


VMacs runs on the VAX host. It 
allows users to store and manage Mac¬ 
intosh files on the VAX’s disk and tape 
drives. Users complete the link with a 
communications package such as 


tual partitioning and protected mode 
operation; message-based, distributed 
priority; video management; the ability 
to run applications written for the IBM 
PC or compatibles; and international 
language support facilities. 

The Series 386 maintains compatibility 
with previously-released NGEN 80186- 
and 80286-based applications. It sup¬ 
ports CTOS applications and runs both 
MS-DOS and Unix System V operating 
systems. 

A basic configuration, featuring IM 
byte of memory, a 64K-byte floppy disk 
drive, and a 40M-byte hard disk drive, 
starts at $9000. For more information, 
contact Convergent Technologies, 2700 
N. First St., San Jose, CA 95150-6685; 
(408) 434-2848. 
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Mac240. VMacs uses XModem Mac- 
Binary protocol for file transfers, so can 
use a variety of terminal emulation prod¬ 
ucts. VMacs retails for $399 for a single- 
user license and $999 for a multiuser 
license. 

The Mac240 communications package 
runs on the Macintosh. It offers three 
options: Macintosh access to VMacs, 
Macintosh access to VAX application 
software, and Macintosh-to-Macintosh 
communication. Mac240 provides emu¬ 
lation of DEC’S VT240 text and graphics 
terminal, including Regis graphics. Its 
latest release adds emulation of Tek¬ 
tronix 4010 and 4014 graphics terminals 
and support for 11 international charac¬ 
ter sets. Version 1.3 retails for $199. 

Reggie allows graphics communication 
from the Macintosh to the VAX and to 
DEC peripherals. The software converts 
MacDraw, MacPaint, and Clipboard im¬ 
ages for the VAX by converting Apple- 
based graphics instructions to DEC’S 
Regis and Sixel formats. It retails for 
$99. 

Contact White Pine Software, 

PO Box 1108, Amherst, NH 03031; 

(603) 673-8151. 
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Q-2C translates Q-Pro 4 

Binary Research has announced Q-2C, 
a system that translates the fourth- 
generation language database Q-Pro 4 
into C language source code. 

The initial release of Q-2C translates 
for PC-DOS and MS-DOS. Future ver¬ 
sions are planned for the AT&T 7300, 
the AT&T 3B, and the Tandy 1600. 

First an application is written, tested, 
and debugged using the Q-Pro 4 lan¬ 
guage. Developers may embed C code 
for later compilation, if they wish. Using 
Q-2C then produces C code, compiled 
and linked as usual, to yield executable 
program object files. 

Q-2C costs $1000. There are no 
royalties on the compiled C programs. 
Contact Binary Research, 7100 E. Valley 
Green Rd., Fort Washington, PA 19034; 
(215) 233-5300. 



Intel 80386 powers Convergent’s Series 386 NGEN 
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Convergent’s Series 386 NGEN features the Intel 80386 and the CTOS II operating 
system. 
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AI development language works with Macintosh 


ExperTelligence has announced Exper- 
Common Lisp, an artificial intelligence 
development system for the Apple Mac¬ 
intosh desktop computer. 

According to the company, Exper- 
Common Lisp observes the specifications 
of the Common Lisp Committee and al¬ 
lows development of applications for de¬ 
livery independent of the Lisp 
environment. 

Features include more than 1100 prim¬ 
itives; an incremental compiler that gen¬ 
erates 68000 native code directly from 
Lisp source code: a memory manage¬ 
ment technique that leaves 300K bytes of 
memory free for the program under de¬ 


velopment; an automatic symbolic de¬ 
bugger; a class system with tools for 
object-oriented programming: direct ac¬ 
cess to the Macintosh Toolbox; integra¬ 
tion of the debugger, class system, and 
toolbox access with the compiler; and an 
optional dead code analyzer. 

ExperCommon Lisp costs $995. The 
optional file compiler costs $495 and the 
dead code analyzer, $1500. Site licensing 
starts at $1350 per year. 

Contact ExperTelligence, 559 San 
Ysidro Rd., Santa Barbara, CA 93108; 
(805) 969-7874. 
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AI technology used to analyze perfonnance 


Boole & Babbage has announced a 
performance management tool that uses 
expert system technology to analyze 
mainframe system performance. Called 
DASD Advisor, the product is an op¬ 
tional post processor on the company’s 
DASD Response Manager. 

DASD Advisor uses system informa¬ 
tion gathered by DASD/RM to identify 
performance problems, analyze their 
causes, and recommend corrective ac¬ 
tion. The program reads and interprets 
the data, and diagnoses I/O perfor¬ 
mance bottlenecks at the channel, con¬ 
trol unit, head-of-string, and device 
levels of the I/O subsystem. 


DASD Advisor provides three analysis 
modes: system balance, volume, and 
workload. The system balance mode 
shows the I/O subsystem from the top 
down. The volume mode shows the sys¬ 
tem from the bottom up. The workload 
mode examines problem volumes 
associated with particular workloads. 

The product will be available in the 
second quarter of 1987. For more infor¬ 
mation, contact Boole & Babbage, 510 
Oakmead Pkwy., Sunnyvale, CA 94086: 
(408) 735-9550. 
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Interface connects VAX and NMX-432 array processor 


Numerix offers the NMX-432 VAXBI 
interface package to connect Digital 
Equipment’s family of VAXBI proces¬ 
sors to the NMX-432 array processor. 

The package features data transfer 
rates up to 5M bytes per second and 


VMS software compatibility. It consists 
of three boards: a DRB32 board con¬ 
necting to the VAXBI systems bus, a for¬ 
mat converter board, and a host-array 
processor interface board. The first two 
reside in the VAXBI logic cage and oc- 


Digital offers boards, networking products 


Digital Equipment Corp. has an¬ 
nounced new VAX computer system 
configurations incorporating memory 
boards of quadruple the previous capac¬ 
ity. The 16M-byte memory arrays expand 
the capacity of the VAX 8500 and VAX 
8550 systems to 80M bytes and the VAX 
8700 and VAX 8800 systems to 128M 
bytes. The boards are also available in¬ 
dividually to expand VAXBI-bus-based 
systems. 

The new VAX 8550 system with 
32M-byte capacity is priced from 
$364,000; the new VAX 8500 16M-byte 
configuration, from $252,000. Individual 


16M-byte memory array boards cost 
$32,000. 

A single-board peripheral processor 
for Q-bus computer systems called the 
KXJll-C acts as a real-time processor, 
coprocessor, or I/O processor. It costs 
$3500. 

VAX DEC/MAP is a set of network¬ 
ing products based on the manufacturing 
automation protocol version 2.1 specifi¬ 
cation. VAX DEC/MAP enables all 13 
models of Digital’s VAX-11/700 and 
VAX 8000 computer systems to commu¬ 
nicate with other systems supporting the 


PCB design software 

Dasoft Design Systems has announced 
a CAD package called Project: PCB 
with schematic capture, board layout, 
and autorouting capabilities for $950. 

The system runs under MS-DOS on the 
IBM PC-XT, PC-AT, and compatibles. 
Graphics options include Hercules 
Monochrome, CGA or EGA with mono¬ 
chrome monitor, and EGA with color 
monitor. The system requires a mouse 
and supports various plotters. 

The Project: PCB system features 
windowing: zoom; pan: user-definable 
schematic and silkscreen symbols: user- 
definable footprints; block move, copy, 
and delete; screen display of unrouted 
traces; single net or full board autorout¬ 
ing; routines for producing netlists, parts 
lists, and hole lists; plot routines for 
camera-ready art; and optional pre¬ 
defined libraries of parts and symbols. 

Demonstration disks are available on 
request. 

For more information, contact Proj¬ 
ect: PCB, PO Box 8088, Berkeley, CA 
94707-8088: (415) 486-0856. 

A companion package called MFG 
provides automatic silkscreen, fabrica¬ 
tion drawing, assembly drawing, and art¬ 
work enhancement capabilities. The user 
can edit artwork on a variable grid with 
a variety of line widths. The package 
costs $500. 

Reader Service Number 45 


cupy adjacent slots, while the third 
resides in the NMX-432. 

For more information, contact 
Numerix, 20 Ossipee Rd., Newton, MA 
02164; (617) 964-2500. 
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MAP specification. It consists of a VMS 
software package with four application 
layer interfaces and network manage¬ 
ment utilities, a communications con¬ 
troller, and cabling. The products range 
in price from $12,000 to $16,500. The 
hardware prerequisite is the MAPserver/ 
Plus Token Interface Module modem 
from Concord Communications ($5745). 

For more information on these DEC 
products, contact Digital Equipment 
Corp., Maynard, MA 01754-2571. 
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Unix system works in the scientific lab 


Crowcard uses BBD 


Masscomp has announced a real-time 
data acquisition computer system de¬ 
signed for scientific laboratory applica¬ 
tions. The Scientifie Laboratory System, 
or SLS, features an enhanced version of 
Unix called RTU and a scientific soft¬ 
ware package called Laboratory 
Workbench. 

According to the company, Labora¬ 
tory Workbench can eliminate program¬ 
ming, or can increase the speed of pro¬ 
gramming in combination with other 
programming languages. It employs 
mouse-driven pull-down menus, pop-up 
displays, graphical icons, and interactive 
controls. Users can input, modify, 
display, and store data without writing 
code. 

The SLS integrates hardware and soft¬ 
ware and offers such features as floating¬ 
point and optional array processors, a 
data acquisition and control processor, 
and other specialized data acquisition in¬ 
terfaces and software. 

The system uses a triple bus architec¬ 
ture and RTU. A proprietary memory 
bus communicates with a Multibus 


through a hardware adapter. This design 
reputedly increases bus bandwidth from 
3M bytes per second to 6M bytes per sec¬ 
ond. A 32-bit asynchronous memory bus 
operates at 12M bytes per second. 

The SLS offers two network stan¬ 
dards: Ethernet and X.25. Available lan¬ 
guages include Ada, C, Pascal-2, Franz 
Lisp, and ANSI-validated Fortran. 

Mass storage is based on the small 
computer systems interconnect. The sys¬ 
tem includes 650K bytes of formatted 
floppy disk memory and 71M bytes of 
formatted Winchester disk memory. 

The Scientific Laboratory System is 
available in two configurations. The 
lower-end system costs $29,900 and 
employs a multifunction card for data 
acquisition. The other configuration 
costs $39,800 and features high-speed 
data acquisition, plus a floating-point 
capability. For more information, con¬ 
tact Masscomp Scientific Products 
Group, One Technology Park, Westford, 
MA 01886: (617) 692-6200. 
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Applied Physics has announced the 
Crowcard I-bus Monitor. Built on a stan¬ 
dard PC card, the Crowcard works in 
IBM PC, PC-XT, and PC-AT comput¬ 
ers and compatibles. The card views bus 
activity without interfering with normal 
operation. It also works with software 
diagnostics. 

The product features 50 LEDs 
grouped by function, monitoring differ¬ 
ent lines on the bus. It monitors supply 
voltages, address and data lines, the sys¬ 
tem clock, I/O and memory activity, in¬ 
terrupts, and so on. 

The Crowcard retails for $249. The 
upcoming Crowcard II will apply directly 
to IBM PC-AT compatibles. Contact 
Applied Physics, 1291 E. Cumberland 
Ave., W. Lafayette, IN 47906; 

(317) 497-1718. 

Reader Service Number 49 

Systems aid simulation 

Gould Computer Systems Division has 
announced a line of simulation and 
training computer systems called the 
Selconnection, based on a 32-bit super¬ 
microcomputer named Microsel and sup¬ 
ported by Gould’s Reflective Memory 
for interprocessor communications. 

Microsel is a CMOS gate-array imple¬ 
mentation, code-compatible with 
Gould’s superminicomputers. Its instruc¬ 
tion set is fully compatible with that of 
the Gould Concept 32/67. The unit fea¬ 
tures a 32-bit CPU, a floating-point co¬ 
processor, 2M bytes of memory, and an 
SCSI interface. 

Another member of the Simulation 
Environment Links family, Selpac, is a 
host packaged system for distributed 
processing applications in real-time en¬ 
vironments. It consists of a 14-slot 
chassis with power supplies and cooling 
units, a CPU, memory, FPA, and 
cabinet. Selpac can host multiple pro¬ 
cessing nodes through Reflective Memo¬ 
ry. It can be expanded by plugging in an 
additional CPU and floating-point ac¬ 
celerator, or by adding peripherals. 

Multisel contains multiple Microsel 
units (one to four) in one cabinet, 
expandable to eight units in two 
cabinets, connected by Reflective 
Memory. 

In OEM quantities, Microsel costs 
$19,950. A Selpac with peripherals, in¬ 
cluding a 337M-byte disk and tape, is 
OEM-priced at $39,920. Contact Gould 
Computer Systems Div., PO Box 409148: 
Fort Lauderdale, FL 33340-9148: 

(305) 587-2900. 
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The Masscomp Scientific Laboratory System features a version of Unix, software, 
and data acquisition interfaces. 
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ISI offers Optimum 400 Series, hardware 


Integrated Solutions has announced 
the Optimum 400 Series of technical 
computers and workstations, incor¬ 
porating ISI’s new CPU board based on 
the 25-MHz Motorola 68020 micropro¬ 
cessor. According to the company, the 
new board’s architectural changes in¬ 
clude integration of cache memory and 
the memory management unit, and vir¬ 
tual DMA. 

The Optimum 400 Series is available in 
three main processor models based on 
the VMEbus: the 408S has 8 slots and 
costs $18,500; the 416S has 16 slots for 
$20,500; and the 424S has 24 slots for 
$25,500. Standard is 4M bytes of main 
memory. Systems can be configured with 
memory cards to a maximum of 56M 
bytes of total memory. All of the systems 


Software enhances DASnet 

DA Systems offers two software pack¬ 
ages as part of its DASnet wide area net¬ 
work: Node and IsoBridge. 

Node software allows users to com¬ 
municate over the DASnet WAN using 
either ASCII or binary electronic mail 
and files. The program runs on the IBM 
PC, PC-AT, and compatibles. 

Node computers call another comput¬ 
er to deliver memos and files. During the 
same call they pick up the memos and 
files sent to them. This allows computer 
communications without coordinating 
the call with the person at the destina¬ 
tion. Nodes communicate through their 
associated hub. 

IsoBridge software uses the QNX 
multiuser, multitasking operating system. 
IsoBridge combined with other DASnet 
software forms a distributed WAN. It 
incorporates the “hooks” that program¬ 
mers need to implement networked 
applications. 

IsoBridge features uninterrupted 
memo and file transmission and receipt, 
notification upon message arrival, securi¬ 
ty, error checking, automatic retries, 
automatic processing, and support for 
the Hub option, which allows computers 
running Node to become accessible 
through DASnet. 

Node software costs $39.95 for DOS- 
node or QNX-Node. QMail-Node 
(multiuser) costs $139.83. IsoBridge soft¬ 
ware costs $595, $1190 for unlimited 
nodes on a QNX LAN. The Hub option 
costs an additional $200. Contact DA 
Systems, 1503 E. Campbell Ave., Camp¬ 
bell, CA 95008; (408) 559-7434. 
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include two RS-232-C serial ports. 

Workstations include the same fea¬ 
tures plus a graphics subsystem in color 
or monochrome. The 408M (mono¬ 
chrome) costs $24,400; the 416M, 
$26,400; and the 424M, $31,400. 

ISI also offers a 494M-byte disk 
subsystem for its VME-based family of 
workstations. Called the VDS494, the 
eight-inch Winchester drive has an 
embedded-servo design. The drive is 
available as an option on the Optimum 
V16 and V24 computers and worksta¬ 
tions, as well as the 416 and 424 models 
of the Optimum 400 Series. It costs 
$18,900. 

A VME Ethernet card for ISI VME- 
based systems and workstations uses the 


LAN links IBM 3270-PCs and 

ACS Telecom has announced 10-3270, 
a local area network designed to link 
IBM 3270-PCs and 3270-ATs in a dis¬ 
tributed processing environment. 

According to the company, users can 
share data, programs, and peripherals 
over the network, even when in a main¬ 
frame session. 

Integrated 10-3270 utilities include a 
custom menu system, electronic mail, 
transparent operation, and print 
spooling. 

ACS Telecom has also announced 
10-Disk, an internal hard-drive kit for 
the IBM PC-AT, Compaq Deskpro 286, 


AM7990 LAN controller for Ethernet 
(Lance) from Advanced Micro Devices 
and a Motorola MC68000 CPU at 10 
MHz. It costs $1900. 

The VME-HSMEM-8 and VME- 
HSMEM-4 are memory boards for ISPs 
VME-based Optimum series. The VME- 
HSMEM-8 board is an 8M-byte dual- 
ported memory board that operates in a 
synchronous mode. It costs $9000 as a 
standalone unit. The VME-HSMEM-4 is 
a 4M-byte board with the same features. 

It costs $5000 as a standalone unit. 

For more information, contact 
Integrated Solutions, 1140 Ringwood 
Court, San Jose, CA 95131; 

(408) 943-1902. 
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and compatibles. Capacities range from 
50M bytes to more than 300M bytes. The 
system uses a 16-bit controller that 
reputedly runs a one-to-one interleave. 

The storage systems come as the 
S-Series and E-Series. The S-Series 
employs an ST506-type interface, while 
the E-Series employs an ESDI interface. 
Prices start at $3995. 

The 10-3270 network retails for $995 
per node. Contact ACS Telecom, 25825 
Eshelman Ave., Lomita, CA 90717; 

(213) 325-3055. 
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System 9000 environment targets development 


Philips and Signetics Microsystems has 
announced the System 9000, a VMEbus- 
based development and target envi¬ 
ronment. The System 9000 provides 
OEMs and systems integrators with a 
real-time environment for applications 
development. 

The basic system, PG9105, comes with 
a seven-slot VMEbus backplane and a 
standard PG2009 11-MHz SCN 68010 
single-board computer with 68451 
MMU. The PG9105 also includes a 
PG2205 IMB DRAM memory module, 
PG3102 disk controller, and 3.3M-byte 
floppy disk drive. 

The System 9000 PG9106 includes all 
the features of the PG9105 plus a 
53.33M-byte Winchester disk drive. 

In addition to the pSPS-68K kernal, 
users have the option of adding Unix or 


CP/M operating systems. Unifive (Unix 
System V, Release 2, with Berkeley 
enhancements) features an optimized C 
compiler, a Fortran-77 compiler, IEEE 
floating-point compatibility, record/file 
level locking, text loitering, text sharing, 
and bad block handling. 

The PG9105 basic configuration costs 
$5995; the enhanced PG9106 costs 
$7995. The optional CP/M-68K in the 
PG9106 configuration costs $495. 

Unifive configured for the PG9106 costs 
$1995, with a charge of $300 for the 
manual. 

For more information, contact Philips 
and Signetics Microsystems, PO Box 
3409, Sunnyvale, CA 94088-3409; 

(408) 991-3544. 
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2400 bps modem provides 
MNP error control 

Racal-Vadic has announced the 
2400VP, a full-duplex modem that pro¬ 
vides MNP error control, ATPlus com¬ 
patibility, speed conversion, an 
automatic voice-to-data switching cir¬ 
cuit, front panel control, and nonvolatile 
memory for a price of $595. 

The 2400VP is compatible with the 
Hayes AT dialing protocol. The ATPlus 
command set expands the existing Hayes 
commands and dlows the modem to 
display S# register values, control MNP 
error checking, and control speed con¬ 
version, among others. 

For more information, contact Racal- 
Vadic, 1525 McCarthy Blvd., Milpitas, 
CA 95035: (408) 946-2227. 
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Modem works with portables 

Touchbase Systems has announced the 
WorldLink 1200 portable modem. Ac¬ 
cording to the company, the Hayes- 
compatible, battery-powered modem was 
designed for use with both portable and 
desktop computers. It provides a direct 
interface for acoustic cup operation at 
both 300 and 1200 bps. 

Features include autodial, auto¬ 
answer, pulse and tone dialing, and 
either a male or female DB-25 connector. 
Four LEDs provide visual status of call 
progress, carrier detect, high/low speed, 
and low battery condition. 

The modem supports Bell 103/212A 
standards and CCITT V.21 (300 bps) and 
V.22 (1200 bps) standards. The Bell and 
CCITT standards are switch and soft¬ 
ware selectable. 

The WorldLink 1200 retails for $199. 
OEM versions with flexible configura¬ 
tions are available. Contact Touchbase 
Systems, 16 Green Acre Lane, North- 
port, NY 11768; (516) 754-3491. 
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NEW LITERATURE 


Expert Systems and Knowledge 
Engineering. Editor T. Bernold has 
brought together 19 AI application case 
studies that help bridge the gap between 
technical knowledge and managerial and 
organizational questions regarding ap¬ 
plicability and the introduction of these 
systems. Elsevier Science Publ. Co., 

Inc., PO Box 1663, Grand Central Sta., 
New York, NY 10163; $51.75. 

Prolog Programming for Artificial In¬ 
telligence. Ivan Bratko introduces Prolog 
as a practical programming tool and 
shows how Prolog programs are devel¬ 
oped. Its use in problem solving and 
heuristic search, expert systems, game 
playing, and pattern-directed systems 
underlines Prolog’s relevance in AI pro¬ 
gramming. Addison-Wesley Publ. Co., 
Reading, MA 01867; (617) 944-3700; 
$25.95. 

Essential Lisp. This 352-page book leads 
readers through LISP and its applica¬ 
tions to AI. John Anderson, Albert Cor¬ 
bett, and Brian Reiser also provide 
hands-on exercises for each of the topics 
covered. Addison-Wesley Publ. Co., 
Reading, MA 01867; (617) 944-3700; 
$23.95. 

Translation of Nikkei High Tech Report. 
This biweekly publication of the Nikkei 
Industry Research Institute of Japan of¬ 
fers information on Japanese technologi¬ 
cal developments, focusing on such areas 
as electronics, data processing, telecom¬ 
munications, biotechnology, robotics, 
new materials, and new energy sources. 
WANT Publishing Co., 1511 K St., 
N.W., Washington, DC 2(X)05; (202) 
783-1887; annual subscription, $580. 

GaAs marketing report. Gallium 
Arsenide Markets: Current Status & 
Strategic Perspectives predicts the 
growth of the GaAs IC market will be 
considerably slower than previously ex¬ 
pected. A major portion of the report is 
devoted to the review of the major mer¬ 
chant and captive industry participants, 
with emphasis on their production 
capabilities, R&D efforts, products, 
product strategies, and corporate pro¬ 
files. HTE Management, Inc., 4575 
Scotts Valley Dr., Ste. 105, Scotts 
Valley, CA 95066; (408) 438-5937; $1975. 

Directory of Special Libraries and Infor¬ 
mation Centers, lOth ed. Descriptive 
guide featuring over 18,000 libraries, ar¬ 


chives, and similar facilities maintained 
by business firms, nonprofit organiza¬ 
tions, educational institutions, govern¬ 
ment agencies, and others. Information 
about subject interests, materials held, 
journal and newspaper subscriptions, 
computer-based services offered, net¬ 
work or consortia memberships, staff 
sizes, and publications is provided for 
each facility. Gale Research Co., Book 
Tower, Detroit, MI 48226; (313) 
961-2242; no price provided. 

US system designers to increasingly 
customize products. According to 
Customizing VLSI Integrated Circuits 
Update—A User’s Guide to the ASIC 
Design Center, regional VLSI IC design 
centers will assist more than 60 percent 
of all system designers in developing 
application-specific integrated circuits 
(ASICs), representing 75 percent of the 
$7.2 billion in ASIC sales. “The world¬ 
wide electronic industry is undergoing an 
unprecedented structural shift, with the 
future emphasis on service, design assis¬ 
tance, and regional support,” asserts 
author Osvaldo Viva. Electronic Trend 
Publications, 12930 Saratoga Ave., Ste. 
Dl, Saratoga, CA 95070; (408) 996-7416: 
$985. 

Proceedings of the 1986 National Com¬ 
puter Conference. Contains the formal 
papers, complete with illustrations, 
presented at the conference in the 
following program areas: artificial in¬ 
telligence, networking, research and de¬ 
velopment, management issues, soft¬ 
ware, end user computing, educational 
and societal issues, and controversy. 
American Federation of Information 
Processing Societies, Inc., 1899 Preston 
White Dr., Reston, VA 22091; (703) 
620-8918; $40 for constituent society 
members; $80 for nonmembers. 

OAC ’86 Conference Digest. Collection 
of 37 papers presented at the AFIPS- 
sponsored Office Automation Con¬ 
ference held March 24-26, 1986 in 
Houston. Papers emphasize practical ap¬ 
plications and approaches to office 
automation technologies in areas in¬ 
cluding: user interfaces: image process¬ 
ing; artificial intelligence; voice and elec¬ 
tronic mail; decision support systems; 
electronic document delivery: microcom¬ 
puter application development; systems 
planning; networks: and micro/main¬ 
frame interconnection. AFIPS, 1899 
Preston White Dr., Reston, VA 22091; 
(703) 620-8918; $28. 
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CALL FOR PAPERS 



MINNEAPOLIS 
MINNESOTA 
OCTOBER 5-7 
1987 


12th Conference On Local Computer Networks 


Sponsored by: IEEE COMPUTER SOCIETY TC-COMPUTER COMMUNICATIONS 


Theme: 

The emphasis of this conference is on practical experience 
using local computer networks, including running 
applications by users, researchers, and vendors. 

This year's focus will be on internetworking, and papers 
that cover these areas are especially sought. Papers that 
address gateway/bridge bottlenecks and now to resolve 
them are of special interest. 

Topics of Interest: 

Current Bottlenecks: Internetworking -- Interconnect levels - 
Standards - Connectivity - Protocols - Incompatibilities - 
Global Management - Routing - Performance Monitoring. 

Practical Experience: Distributed applications - Network 
operating systems - Network management - Integrated 
Services - Application Protocols - Performance evaluation 
and measurement - Installation planning and experience. 

Information for Authors: 

Submit 6 full copies. The first page must contain; title, 
authors' names, affiliations, complete mailing address, 
telephone number, and an abstract ^ May 1,1987. 

Submit papers (double-spaced - in English) to; 

Dr. Robert Linebarger 
Computer Science Dept. 

242TMCB 

Brigham Young University 
Provo, UT 84602 
(801) 378-2835 

LINEBARG@BYUCSA.B1TNET 


Important Dates: 

Submission Deadline May 1,1987 

Acceptance Notification June 15,1987 

Camera Ready Copy Due July 15,1987 

Tutorials: 

Tutorial proposals are solicited (send to General Chairman) 
for special pre-conference (October 5) tutorials. Proposals 
must be received by April 1,1987. 

Organizers: 

General Chairman; Stephana Johnson, Start, Inc. 

Program Committee: 

Paul Amer, Univ. of Delaware 

Phil Edholm, Sytek 

Dave Feldmeier, MIT 

Mario Gerla, UCLA 

Ken Hardwick, Network Systems 

Susan Hauser, NIH 

Gregg Hopkins, Ungermann-Bass 

Debra Kornblum, Bell Comm. Research 

Rod Merry, CNT 

Dennis Mok, Western Illinois Univ. 

MikeMulloy.CMU 

Dale Murray, General Research 

Dale Niebauer, Novell 

Kanti Prasad, Univ. of Lowell 

Juan Pimental, GM 

Gerry Popk, Locus 

Jai Rao, McDonnell Douglas 

Howard Salwen, Proteon 

Gerry Samsen, Tl 

Paul Schmidt, Wright-Patterson 

Bhavani Thuraisingham, Honeywell 

Al Weaver.Univ. of't/irginia 

Stu Wecker, Technology Concepts 


12th Conference on Local Computer Networks I intend to submit a paper entitled; 
C/0 Stephane Johnson 

General Chairman — 

Start, Inc. 

10301 Toledo Ave. S. Name: 

Bloomington, MN 55437 ——— 

(612) 831-2122 Address:_ 

Please send me: __ 


Zip: 


Information as it becomes available 
Advanced Program 


Phone: 





























Recent 1C Announcements 


MODEL AND R.S. 

FUNCTION COMPANY COMMENTS _NO. 


HD6345/HD6445 
CRT controller 


HS9390 

DAC 


COM9064LJP 

Controller 


TSC7129 
A/D converter 


Hitachi America, Ltd. 
2210 O’Toole Avenue 
San Jose, CA 95131 
(408) 435-8300 


Hybrid Systems Corp. 
22 Linnell Circle 
Billerica, MA 01821 
(617) 667-8700 


Pin- and software-compatible with industry standard NMOS 70 
HD6845S and providing display control for raster scan-type 
CRTs, the 68 (HD6345) and 80 family MPU (HD6445) have 
256-character by 256-line screen format control at a 4.5-MHz 
clock rate, four split screens, scrolling, two programmable 
cursors, and dual-port memory access control. Available in 
40-pin dual in-line and 52-pin J-lead PLCC packages. Cost 
(10,000’s) $4.20 each. 

This 16-bit digital-to-analog converter has a settling time 71 

(4mA step to -I- / - 0.006 percent) of 75 ns. Integral linearity 
is specified at -H / - 0.004 percent FSR max, and initial gain 
errors at + 1 percent max while initial offset errors are 
specified at -nO.l percent (unipolar) and -1-0.2 (bipolar). Over 
the commercial and military temperature ranges, gain drift is 
-I- 10 ppm/'C; offset drift, -(-2 ppm/°C (unipolar) and -I- 10 
ppm/°C (bipolar). Packaged in a 32-pin metal triple DIP. 

Cost (lOO’s) ranges from $100 to 200. 


Standard Microsystems Corp. 
35 Marcus Blvd. 

Hauppauge, NY 11788 
(516) 273-3100 


This -I- 5V VLSI controller for implementing the IBM 3270 72 

Coax Type “A” protocol provides a physical link between an 
IBM 3274 or 3276 controller and peripheral equipment. Spe¬ 
cial handshake and frame format, as well as parity generation 
and error detection, are also implemented for communication 
over a distance of 5000 feet. Includes two built-in diagnostic 
features for checking the functionality of the chip, line 
drivers/receivers, and the isolation transformer. Packaged in 
a plastic leaded chip carrier. Cost (lOO’s); $18.65. 


Teledydne Semiconductor 
1300 Terra Bella Ave. 

Box 7267 

Mountain View, CA 94039-7267 
(415) 968-9241 


This 4‘A-digit analog-to-digital converter drives a multiplexed 
liquid crystal display, is fabricated in low-power CMOS, and 
requires 500fiA and 9V. It produces readings accurate to 0.005 
percent of full scale and resolution to 10/iV. The TSC7129 is 
pin-for-pin compatible with the ICL7129 from Intersil and 
has internal phase compensation of the integrator amplifier. 
Depending on packaging (DIP, CerDIP, PLCC) and pin 
number, prices range from $7 to 14.05 for lOO’s. 
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TC511000P-85 

DRAM 


TMM2089C 

SRAM 


VM10A24 
SRAM module 


Toshiba America, Inc. 
2692 Dow Ave. 
Tustin, CA 92680 
(714) 832-7300 


Toshiba America, Inc. 
2692 Dow Ave. 
Tustin, CA 92680 
(714) 832-6300 


This IM-bit DRAM with an access time of 85 ns is organized 74 
as IM bit X 1 bit using CMOS technology. Other features are 
its multiplexed address inputs, operability from a single 5V 
power supply with a 10 percent tolerance, and direct interfac¬ 
ing with STTL devices. Power requirements are 385mW and 
5.5mW standby. Cost (lOO’s): $27. 

This NMOS SRAM is organized as 8192 9-bit words and 75 

features an aecess time of 35 ns. Power requirements are 
120mA max and 10mA standby. Operation is from a single 
5V power supply with a 10 percent tolerance. Available in 
versions with 55-, 45-, or 35-ns aecess times. Comes in 23-pin 
CerDIP packages. Cost (lOOO’s): $36.80. 


Vitarel Microelectronics, Inc. 
3572 Corporate Court 
San Diego, CA 92123 
(619) 292-8353 


This IM-bit SRAM module is organized as 64K bits x 16 bits 76 
and consists of four 32 x 8 SRAM DIPs, along with decoder 
circuitry and decoupling capacitors—all mounted on the top 
and bottom surfaces of a 40-pin ceramic substrate. Available 
in commercial, military (MlL-STD-883), or class S version, 
and with access times of 100, 150, and 200 ns. Cost for 
commercial version: $350; military, $510. 
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Recent Microsystem Announcements 


MODEL AND R.S. 

FUNCTION COMPANY COMMENTS_NO. 

This plug-in board gives IBM desktop computers full duplex 80 
communications capability at 56K-bit speed and enables such 
computers to connect to switched data network services being 
offered by AT&T and Bell companies. Price not indicated. 


Speedlinx 56 DSP Technology Corp. 


Communications board 

1325 Capital Pkwy. 

Carrollton, TX 75006 
(214)245-8831 

DECmate III Plus 

Word processing system 

Digital Equipment Corp. 
Maynard, MA 01754-2571 

DQ696 

Disk controller 

Distributed Logic Corp. 

1555 S. Sinclair St. 

PO Box 6270 

Anaheim, CA 92806 
(714) 937-5700 

DRAM-5A, DRAM-5B; 
CPU-386 
Dynamic-memory 
boards; 

VMEbus board 

Force Computers, Inc. 

727 University Ave. 

Los Gatos, CA 95030 

CM 201, CM 210 

CD ROM drives 

Laser Magnetic Storage 
International 

4425 Arrows West Dr. 

Colorado Springs, CO 80907 
(303) 593-4237 

PC/2400, PC/2400C, 
PC/9624C 

Modems 

May-Craft Information Systems, 
Inc. 

4312 Belt wood Pkwy. South 
Dallas, TX 75244 
(800) 527-7456 

PC/XT Expanded 
Memory Board, AT 
Expanded Memory 
Board 

Memory boards 

Micron Technology, Inc. 

2805 E. Columbia Rd. 

Boise, ID 83706 
(208) 383-4000 

PG2030; PG2260: 
PG2210 

VMEbus processor 
module; memory 
module; dynamic RAM 
module 

Philips and Signetics 
Microsystems 

811 E. Arques Ave., MS 27 

PO Box 3409 

Sunnyvale, CA 94088-3409 
(408) 991-3544 

PML86 

Multilingual add-on 
card and software 

PML Systems 

3139 E. Almond Ave. 

Orange, CA 92669 
(714) 771-7744 


The DECmate III Plus ($4695) is a hard-disk version of the 81 
DECmate III ($2695) floppy-disk-based word processing sys¬ 
tem. Either will operate as a stand-alone workstation or as a 
terminal on a host system; either will provide VTIOO or 
VT2(X) series terminal emulation access to a LAN Terminal 
Server or directly to a VAX host. 

The DQ696 ($1450) provides full compatibility with the 82 

enhanced small disk interface (ESDI) standard and permits 
attachment of one or two drives to DEC’S Micro VAX, 

MicroPDP-11 and LSI-11 computers. 


The DRAM-5A ($2095) and DRAM-5B ($2895) offer, 83 

respectively, 2 and 4 million bytes of dynamic RAM that are 
automatically corrected for all single-bit errors. Both are true 
32-bit boards (address and data) that can be used with 
VMEbus-compatible processors. The CPU-386 ($5775) is an 
80386-based VMEbus board. 

Both of these half-height 514-inch drives are designed to 84 

access up to 600M bytes of digitally encoded data on standard 
120-mm (4.72-inch) compact disks. The CM 201 has a propri¬ 
etary interface designed for the IBM PC family and compati¬ 
bles and the CM 210 has an embedded SCSI controller. Prices 
not indicated. 

The PC/2400 ($699) is a 2400-baud modem that incorporates 85 
MNP protocol Class 4 service, which provides error-free 
transmission and achieves approximately 2900-bps through¬ 
put. The PC/2400C ($799) adds data compression (MNP 
Class 5); typical throughput is 4800 bps. The PC/9624c 
($1799) incorporates the highest level of MNP (6), and adds 
universal link negotiation. 

The PC/XT Expanded Memory Board ($325) comes with 2M 86 
bytes of DRAM installed and tested. The 4M-byte AT 
Expanded Memory Board comes in two versions. The first 
($725) operates with zero wait state at 6 MHz, and with one 
wait state at 8, 10, and 12 MHz. The second ($825) operates 
with zero wait state at 6 and 8 MHz. 

The PG2030 comes in three versions: the PG2030, which 87 

features an SCN 68010-based CPU that operates at 10 MHz; 
the PG2031, which has all the features of the PG2030, plus a 
68451 memory management unit; and the PG2035, which op¬ 
erates at a 12.5 MHz rate and offers all the features of the 
PG2030. The PG2260 is designed for SRAM, ROM/EPROM, 
and EEPROM applications. The dynamic RAM module is 
available in two versions: the PG2210, which offers 256K 
bytes of dynamic RAM, and the PG2211, which offers IM 
byte. Prices available upon request. 

Designed for the IBM PC and compatibles, the PML86 88 

($375) allows non-English-speaking users to run English-lan¬ 
guage applications programs in their own languages. 

Languages supported include French, Spanish, German, 

Greek, Italian, Russian, Swedish, Finnish, Thai, Vietnamese, 
and Sanskrit. 
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CALL FOR PAPERS 


Call for papers for Computer 


Computer magazine seeks articles that 
cover the state of the art and important 
new developments in computer science, 
technology, and applications. Aimed at a 
broad audience with diverse interests and 
experience. Computer usually publishes 
surveys or tutorials that facilitate the 
transfer of technology from university to 
industry, from research to applications, 
and across specialized fields. Submit sbi 
copies of the manuscript, including il¬ 
lustrations, references, and authors’ 
biographies, to 

• Bruce Shriver 

IBM T.J. Watson Research Center 
Route 134 

PO Box 704, H0-B04A 
Yorktown Heights, NY 10598 
(914) 789-7626 
Compmail + \ b.shriver 
CSnet: shriver@ibm.com 
Vnet: shriver at yktvmh 

Computer also seeks articles on topics 
relevant to upcoming special issues. Sub¬ 


mit six copies of the manuscript directly to 
the relevant guest editor: 

• Integrated Design and Programming 
Environments: Articles for com¬ 
plementary issues of Computer and 
IEEE Software are due March 1, 

1987. Submit survey and tutorial ar¬ 
ticles, intended for publication in 
Computer, to David Notkin, Dept, of 
Computer Science, FR-35, University 
of Washington, Seattle, WA 98195; 
CSnet, Notkin®Washington; phone, 
(206) 545-3798. Submit more special¬ 
ized articles and research reports, in¬ 
tended for publication in IEEE Soft¬ 
ware, to Peter Henderson, Computer 
Science Dept., SUNY, Stony Brook, 
NY 11794-4400; CSnet, PBH@SUNY- 
SBCS; phone, (516) 246-8618. 

• Standards: Material is also sought for 
the “Standards” department. For 
details regarding scope and length, 
contact the department editor: Helen 
M. Wood, National Bureau of Stan¬ 


dards, B154 Technology, Gaithers¬ 
burg, MD 20899; (301) 975-3240. 

Lastly, Computer seeks special-issue pro¬ 
posals and articles in the following topic 


• optical computing, 

• electronic publishing and technology, 

• the European computer industry, 

• fabrication and packaging 
technologies, 

• noncoded information, 

• computer-integrated manufacturing, 

• technology transfer process, 

• computers in consumer electronics, 
automobiles, etc., 

• design and implementation of large- 
scale systems, and 

• engineering and scientific worksta- 


Prospective guest editors and authors 
should submit proposals and articles 
directly to Bruce Shriver. 


1987 Design Automation Conference 
(ASME): September 27-30, 1987, Boston. 
Submit five copies of the manuscript by 
March 1, 1987, to S.S. Rao, School of 
Mechanical Engineering, Purdue University, 
West Lafayette, IN 47907; (317) 494-5699. 


IEEE Workshop on Languages for Automa¬ 
tion: August 24-27, 1987, Vienna. Submit 
papers by March 1, 1987, to M. Tauber, 

Dept, of Computer Science, University of 
Pittsburgh, Pittsburgh, PA 15260. 

11th Symposium on Computer Applications 
in Medical Care: November 1-4, 1987, Wash¬ 
ington, DC. Submit papers by March 6, 1987, 
to SCAMC Secretariat, George Washington 
University Medical Center, Office of Continu¬ 
ing Medical Education, 2300 K St. NW, 
Washington, DC 20037. 

12th Structured Methods Conference: August 
3-7, 1987, Grand Rapids, Michigan. Submit 
two copies of an abstraet that is half a page to 
a full page in length by March 13, 1987, to 


James S. Weber, PO Box 603, Gurnee, IL 
60031-0603. 

AAAI Workshop on Spatial Reasoning and 
Multisensor Fusion: October 5-7, 1987, St. 
Charles, Illinois. Submit three copies of an 
extended abstract or a full-length paper 
before March 15, 1987, to Su-shing Chen, 
Dept, of Computer Science, University of 
North Carolina, Charlotte, NC 28223 or Avi 
Kak, Robot Vision Lab, Electrical Engineer¬ 
ing Bldg., Box 121, Purdue University, West 
Lafayette, IN 47907. 

CCDC-87, Computer Communication for 
Developing Countries: October 27-30, 1987, 
New Delhi, India. Submit four copies of 
papers (3000 to 8000 words long) by March 
15, 1987, to S. Ramani, National Centre for 
Software Technology, Gulmohar Cross Rd. 
No. 9, Juhu, Bombay 400049, India; phone 
629574 or 629606. 

IEEE/ACM Symposium on the Simula¬ 
tion of Computer Networks (ACM, 
SCS): August 5-7, 1987, Colorado Springs, 


Colorado. Submit papers before March 15, 
1987, to Michael Green, Network Systems, 
Suite 200, 501 Church St. SE, Vienna, VA 
22180 (industry papers) or Edgar Sibley, 
George Mason University, 4400 University 
Dr., Fairfax, VA 22030 (university papers). 

International Conference on Supercomputing 
(IFIP, SIAM): June 8-12, 1987, Athens. Sub¬ 
mit five copies of the paper by March 15, 
1987, to Elias Houstis, Dept, of Computer 
Science, Purdue University, West Lafayette, 
IN 47907 (authors in the Americas) or T. 
Papatheodorou, Computer Technology In¬ 
stitute, PO Box 1122, 26110 Patras, Greece 
(authors in other areas). 

CASE-87, First International Workshop on 
Computer-Aided Software Engineering: May 
27-29, 1987, Cambridge, Massachusetts. Sub¬ 
mit paper on IBM PC or Macintosh format 
diskette by March 18, 1987, to Elliot Chikof- 
sky. Index Technology, 101 Main St., Cam¬ 
bridge, MA 02142; (617) 491-2100, ext. 552. 

Government Microcircuits Applications Con¬ 
ference: October 27-29, 1987, Orlando, 
Florida. Submit double-spaced summaries not 
exceeding two pages by March 23, 1987, to 
Jay Morreale (G-87), 201 Varick St., Rm. 
1140, New York, NY 10014. 

Eighth Annual International Conference on 
Information Systems (ACM, SIM): December 
6-9, 1987, Pittsburgh. Submit four copies of 


Conferences that the Computer Society participates in or sponsors are indicated by the Computer 
Society logo: other conferences of interest to our readers are also included. For inclusion in Call for 
Papers or Calendar, submit information six weeks before the month of publication (e.g., for the May 
1987 issue, send information for receipt by March 15, 1987) to COMPUTER, 10662 Los Vaqueros 
Circle, Los Alamitos, CA 90720. 
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the complete paper (25 pages maximum, in¬ 
cluding illustrations, tables, and references) 
by March 30, 1987, to Charles H. Kriebel, 
Graduate School of Industrial Administra¬ 
tion, Carnegie Mellon University, Pittsburgh, 
PA 15213. 

ITEA-87, 1987 Annual Symposium of the In¬ 
ternational Test and Evaluation Association: 
November 10-12, 1987, Boston. Submit 
abstract of 250 words or less by March 31, 
1987, to William M. Stein, Mitre Corp., MS 
G105, Burlington Rd., Bedford MA 01730. 

Seventh International Conference on Com¬ 
puter Science (IEEE); August 3-7, 1987, San¬ 
tiago, Chile. Submit seven copies of an ex¬ 
tended abstract (10 pages maximum) by 
March 31, 1987, to Hector Garcia-Molina, 
Dept, of Computer Science, Princeton 
University, Princeton, NJ 08544. 

Directions and Implications of Advanced 
Computing: July 12, 1987, Seattle. Submit 
three copies of paper (including abstract and 
heading) by April 1, 1987, to Computer Pro¬ 
fessionals for Social Responsibility, Box 
85481, Seattle, WA 98105. 

11th Western Educational Computing Con¬ 
ference: November 19-20, 1987, San Fran¬ 
cisco. Submit two copies of original papers by 
April 1, 1987, to Oliver Seely, CSU Dom¬ 
inguez Hills, Chemistry, 1000 E. Victoria St., 
Carson, CA 90747. 

ICGATA-87, Second International Con¬ 
ference on Genetic Algorithms and Their Ap¬ 
plications (AAAI, US Navy Center for Ap¬ 
plied Research in AI): July 28-31, 1987, Cam¬ 
bridge, Massachusetts. Send three copies of 
the complete paper by April 1, 1987, to John 
J. Grefenstette, Navy Center for Applied 
Research in AI, Code 5510, Naval Research 
Laboratory, Washington, DC 20375-5000. 

IEEE Expert: Articles are solicited for a 

special issue on AI applications in 
financial expert systems. Authors should sub¬ 
mit descriptions of recent or novel AI applica¬ 
tions to the construction of intelligent systems 
for financial problems by April 1, 1987, to 
the guest editors; Chidanand Apte and John 
Kastner, IBM T.J. Watson Research Center, 
PO Box 218, Yorktown Heights, NY 10598. 

IFIP Conference on Distributed Processing: 
October 5-7, 1987, Amsterdam. Submit five 
copies of the complete paper (20 pages max¬ 
imum) by April 13, 1987, to E.L. Dagless, 
Electrical Engineering, University of Bristol, 
BS8 ITR, England, UK. 

Performance 87 (ACM, AFCET, IFIP): De¬ 
cember 7-9, 1987, Brussels. Submit five copies 
of a complete paper (20 pages maximum) by 
April 13, 1987, to P.-J. Courtois, Philips 
Research Laboratory, 2 Ave. E. Van 
Becelaere, Box 8, B-1170 Brussels, Belgium; 
phone 32(2) 673-41-90. 


February 1987 


CSC-87, 1987 ACM Computer Science Con¬ 
ference, February 17-19, St. Louis. Contact 
Arlan DeKock, University of Missouri-Rolla, 
Computer Science Dept., Rolla, MO 65401; 
(314)341-4491. 

18th Annual SIGCSE Technical Sym- 
posium (ACM), February 19-20, St. 
Louis. Contact Dan C. St. Clair, UMR 
Graduate Engineering Center, University of 
Missouri-Rolla, 8001 Natural Bridge Rd., St. 
Louis, MO 63121-4499; (314) 553-5440. 

Third IEEE Conference on Artificial 
vS? Intelligence Applications, February 
22-28, Orlando, Florida. Contact Jan Aikins, 
Aion Corp., 101 University Ave., fourth 
floor, Palo Alto, CA 94301; (415) 328-9595. 

Workshop on Distributed Information 
Systems: Networks and Applications (IEEE), 
Eebruary 23, Washington, DC. Contact IEEE 
Workshop, 12498 Fan Leaf Court, Fairfax, 
VA 22033; or D. McDysan, (703) 734-2263; or 
B. Jabbari, (301) 428-5660. 

Compcon Spring 87, February 23-26, 
San Francisco. Contact Glen G. 
Langdon, Jr., IBM Dept. K54-802, 650 Harry 
Rd., San Jose, CA 95120-6099; (408) 
927-1818. 

Sixth Annual Phoenix Conference on Com¬ 
puters and Communications (IEEE), Febru¬ 
ary 25-27, Scottsdale, Arizona. Contact Fo- 
rouzan Golshani, Dept, of Computer Science, 
Arizona State University, Tempe, AZ 85287; 
(602) 965-2855. 


March 1987 

20th Annual Simulation Symposium 
^ (ACM, IMACS, SCS), March 11-13, 
Tampa, Florida. Contact James Gantt, 5986 
Dana Dr., Norcross, GA 30093; (404) 
894-3107. 

19th Southeastern Symposium on Sys- 
terns Theory, March 15-17, Clemson, 
South Carolina. Contact Ernest Baxa, Jr., 
Electrical and Computer Engineering Dept., 
Riggs Hall, Clemson University, Clemson, SC 
29634-0915; (803) 656-5900. 


Tutorial Week Orlando 87, March 
16-20, Kissimmee, Florida. Contact 
Ratan Kumar Guha, Computer Science 
Dept., University of Central Florida, Orlan¬ 
do, FL 32816; (305) 275-2341. 

Sixth Symposium on Reliability in 
Distributed Software and Database 
Systems (NASA), March 17-19, Williams¬ 
burg, Virginia. Contact Edwin C. Foudriat, 


NASA, Langley Research Center, Informa¬ 
tion Systems Division, MS 469, Hampton, VA 
23665;(804)865-3535. 

1987 IEEE VLSI Test Workshop, March 
24-25, Atlantic City, New Jersey. Contact 
Wesley E. Radcliffe, IBM East Fishkill, Dept. 
277, Bldg. 321-5E1, Hopewell Junction, NY 
12533; (914) 894-4346. 

Southcon (IEEE), March 24-26, Atlanta. 
Contact Electronic Conventions Manage¬ 
ment, 8110 Airport Blvd., Los Angeles, CA 
90045; (213) 772-2965. 

IEEE Infocom 87, Sixth Annual Joint 
Conference of the IEEE Computer and 
Communications Societies: Global Net¬ 
works—Concept to Realization, March 
30-April 2, San Francisco. Contact IEEE In¬ 
focom 87, 1730 Massachusetts Ave. NW, 
Washington, DC 20036-1903; (202) 371-0101; 
telex 7108250437 lEEECOMPSO. 

Ninth IEEE International Conference 
on Software Engineering (ACM), 

March 30-April 2, Monterey, California. Con¬ 
tact William Riddle, Software Design and 
Analysis, 1760 Bear Mountain Dr., Boulder, 
CO 80303; (303) 499-4782. 

Eourth International Symposium on 
Optical and Optoelectronic Applied 
Science and Engineering (SPIE), March 
30-April 3, The Hague, The Netherlands. 
Contact Joseph Yaver, SPIE, PO Box 10, 
Bellingham, WA 98227-0010; (206) 676-3290. 

1987 IEEE International Conference on 
Robotics and Automation, March 30-April 3, 
Raleigh, North Carolina. Contact Harry 
Hayman, Exeter C3037, Boca Raton, FL 
33434; (305) 483-3037. 


April 1987 


Fourth International Workshop on 
Software Specification and Design 
(AFCET, Agence de ITnformatique, Alvey 
Directorate, LCRST-Japan), April 3-4, 
Monterey, California. Contact David Marca, 
Digital Equipment Corp., Intelligent Systems 
Tech Group, 77 Reed Rd., MS HL02-3/CID; 
Hudson, MA 01749. 

CHI-87, Conference on Human Factors in 
Computing Systems/GI-87, Graphics Inter¬ 
face (ACM, CIPS), April 5-9, Toronto. Con¬ 
tact William Buxton or Ron Baecker, Univer¬ 
sity of Toronto, Computer Systems Research 
Institute, Toronto, Ontario M5S 1A4, 

Canada. 

Electro 87 and Mini/Micro Northeast (IEEE), 
April 7-9, New York. Contact Dale Lither- 
land. Electro and Mini/Micro, 8110 Airport 
Blvd., Los Angeles, CA 90045-3194; (213) 
772-2965. 


February 1987 
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IEEE Computer Society Symposium on 
Office Automation: Integration, Inter¬ 
connection, and Use of Personai Computers 
(NBS), April 27-29, Gaithersburg, Maryland. 
Contact Vincent Lum, Dept, of Computer 
Science, Naval Postgrad School, Monterey, 
CA; (408) 646-2449. 

IEEE Symposium on Security and 
Privacy, April 27-29, Oakland, Califor¬ 
nia. Contact Virgil Gligor, University of 
Maryland, Dept, of Electrical Engineering, 
College Park, MD 20742: (301) 454-8846. 


May 1987 


Eighth IEEE Symposium on Mass 
Storage Systems, May 11-14, Tucson, 
Arizona. Contact Patrick Savage, Shell 
Development Co., PO Box 481, Houston, TX 
77001; (713) 663-2384. 

Compeuro 87, International Conference 
on VLSI and Computers, May 11-15, 
Hamburg, West Germany. Contact W.E. 
Proebster, IBM Germany, Dept. 3280, Sci. 
Tech., Schoenaichen St. 220, Boeblingen 
7030, West Germany. 


IEEE Workstation Technology and 
Systems Workshop, May 12-13, Cherry 
Hill, New Jersey. Contact Ralph J. Preiss, 12 
Colburn Dr., Poughkeepsie, NY 12603. 


1^ Third International Symposium on 
VLSI Technology, Systems, and Ap¬ 
plications, May 13-15, Taipei, Taiwan. Con¬ 
tact Ben M.Y. Hsiao, IBM Corp., Dept. D18, 
Bldg. 707, PO Box 390, Poughkeepsie, NY 
12602 or Morris Chang, ITRI, No. 1, Jen Ai 
Rd., Sec. 2, Taipei, Taiwan. 


Eighth Symposium on Computer 
Arithmetic, May 18-21, Como, Italy. 
Contact Mary Jane Irwin, Dept, of Computer 
Science, 333 Whitmore Laboratory, Pennsyl¬ 
vania State University, University Park, PA 
16802 or Luigi Dadda, Dept, of Electronics, 
Piazza Leonardo da Vinci 32, Politecnico di 
Milano, 1-20133 Milan, Italy. 

CG International 87, Fifth International Con¬ 
ference on Computer Graphics in Japan 
(CGS), May 25-28, Karuizawa, Nagano Pre¬ 
fecture, Japan. Contact Tosiyasu L. Kunii, 
Dept, of Information Science, Faculty of 
Science, University of Tokyo, Hongo, Tokyo 
113, Japan; phone 81 (03) 812-2111, ext. 

4116. 


Dept, of Elec, and Comm., School of Science 
and Engineering, 3-4-2 Okubo, Shinjuku, 
Tokyo 160, Japan; phone 81 (03) 209-3211. 


Mark Scott Johnson, Hewlett-Packard Labs, 
1501 Page Mill Rd., 3024, Palo Alto, CA 
94304-1181. 


Westex 87, Second Western Expert 
Systems Conference, June 2-4, Ana¬ 
heim, California. Contact Westex 87, PO Box 
2111, Fullerton, CA 92633-0111. 

14th International Symposium on Com- 
puter Architecture, June 2-5, Pitts¬ 
burgh. Contact Zary Segall, Computer 
Science Dept., Carnegie Mellon University, 
Pittsburgh, PA 15213; (412) 268-3736. 


ICCV-87, First International Con- 
ference on Computer Vision, June 8-11, 
London. Contact Azriel Rosenfeld, University 
of Maryland, Center for Automation 
Research, College Park, MD 20742; (301) 
454-4526. 


1^1 IEEE Workshop on Software Technolo- 
gy Transfer, June 11-13, Santa Fe, New 
Mexico. Contact Charles Richter, MCC, Soft¬ 
ware Tech. Prog., 9430 Research Blvd., 
Austin, TX 78759. 

NCC-87, National Conference (AFIPS, 
™ ACM, DPMA, SCS), June 15-18, 
Chicago. Contact AFIPS, 1899 Preston White 
Dr., Reston, VA 22091; (703) 620-8900. 

Second Annual Conference on Struc- 
ture in Complexity Theory, June 16-19, 
Ithaca, New York. Contact Alan Selman, 
College of Computer Science, 161 Cullinane 
Hall, 360 Huntington Ave., Boston, MA 
02215; (617)437-8688. 

1987 IEEE Annual Meeting, June 18-19, New 
York. Contact Betty J. Stillman, IEEE Cor¬ 
porate Services, tenth floor, 345 E. 47th St., 
New York, NY 10017; (212) 705-7757. 


NATO Advanced Study Institute on Testing 
and Diagnosis of VLSI and ULSI, June 
22-July 4, Como, Italy. Contact F. Lombardi, 
University of Colorado at Boulder, Campus 
Box 425, Boulder, CO 80309; (303) 492-1437 
or M. Sami, Dept, di Elettronica, Politecnico 
di Milano, Piazza Leonardo da Vinci 32, 
1-20133 Milan, Italy; phone 39 (2) 2399-3516. 


DAC-87, 24th ACM/IEEE Design 
Automation Conference, June 28-July 
1, Miami Beach, Florida. Contact Design 
Automation Conference, P.O. Pistilli, MP 
Associates, 7366 Old Mill Trail, Boulder, CO 
80301; (303) 530-4562. 


July 1987 


CAR-87, Second International Con- 
ference on Com puter-Assisted 
Radiology (ACM), July 1-4, Berlin. Contact 
Michael L. Rhodes, Multi-Planar Diagnostic 
Imaging, Inc., 2730 Pacific Coast Hwy., Tor¬ 
rance, CA 90505; (213) 539-5944. 


FTCS-17, 17th International Symposium on 
Fault-Tolerant Computing (IEEE), July 6-8, 
Pittsburgh. Contact Flaviu Cristian, IBM 
Research K55/801, 650 Harry Rd., San Jose, 
CA 95120-6099. 

ACM SlGGraph 87, July 27-31, 
Anaheim, California. Contact SlG¬ 
Graph 87 Conference Management, HIE. 
Wacker Dr., Suite 600, Chicago, IL 60601. 


August 1987 

IEEE/ACM Symposium on the Simula- 
tion of Computer Networks (ACM, 
SCS), August 5-7, Colorado Springs, Col¬ 
orado. Contact Mitchell Spiegel, GTE 
Systems, 1700 Research Blvd., Rockville, MD 
20850; (301) 294-8400. 

Sixth ACM SlGACT-SlGOps Symposium on 
Distributed Computing, August 10-12, Van¬ 
couver, British Columbia, Canada. Contact 
David Kirkpatrick, Dept, of Computing 
Science, University of British Columbia, Van¬ 
couver, British Columbia, Canada, or Fred B. 
Schneider, Dept, of Computer Science, Upson 
Hall, Cornell University, Ithaca, NY 14853. 

1987 Workshop on Visual Languages, 
August 19-21, Linkoping, Sweden. 
Contact Erland Jungert, FFV Elektronik AB, 
Agatan 29, S-582 22 Linkoping, Sweden. 


NECC-87, Eighth National Educational Com¬ 
puting Conference (ACM, SCS), June 24-26, 
Philadelphia. Contact Frank L. Friedman, 
Computer Activities Bldg., Box JAl, Dept, of 
Computer and Information Sciences, Temple 
University, Philadelphia, PA 19122: (215) 
787-8450. 


IEEE Workshop on Languages for Automa¬ 
tion, August 24-27, Vienna. Contact M. 
Tauber, Dept, of Computer Science, Universi¬ 
ty of Pittsburgh, Pittsburgh, PA 15260. 

September 1987 


1987 International Symposium on 
Multiple-Valued Logic, May 26-28, 
Boston. Contact Dan Simovici, Dept, of 
Mathematics and Computer Science, Univer¬ 
sity of Massachusetts, Boston, MA 02125; 
(617) 929-7966. 


June 1987 

IFIP Workshop on CAD Engines, June 
1-2, Kakaishinlou, Kainkan, Japan. 
Contact Tatsuo Ohtuski, Waseda University, 


zj'x Second International Conference on 
Computer Applications, June 24-26, 

Beijing. Contact Tse-yun Feng, Penn State 
University, Electrical Engineering East Bldg., 
University Park, PA 16802 or Oscar N. Gar¬ 
cia, Dept, of Electrical Engineering and Com¬ 
puter Science, Rm. T-637, George Washing¬ 
ton University, 801 22nd St. NW, Washing¬ 
ton, DC 20052: (202) 676-7175. 

^ SIGPlan 87, Symposium on Interpreters 
and Interpretive Techniques (ACM), 
June 24-26, St. Paul, Minnesota. Contact 


CSM-87, Conference on Software 
Maintenance (AWC, DPMA, NBS, 
SMA), September 21-24, Austin, Texas. Con¬ 
tact Roger Martin, National Bureau of Stan¬ 
dards, Bldg. 225, Rm. B266, Gaithersburg, 
MD 20899; (301) 921-3545. 


ICDCS-7, Seventh International Con- 
ference on Distributed Computing 
Systems, September 21-25, Berlin. Contact R. 
Popescu-Zeletin, Hahn-Meitner-Institut 
Berlin, Glienicker Strasse 100, D-1000, Berlin 
39, West Germany; phone 49 (30) 8009-2594. 
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CAREER OPPORTUNITIES 


RATES: $12 per line, $120 minimum charge (up 
to ten lines). Average six typeset words per line, 
nine lines per column inch. Add $10 for box num¬ 
ber. Send copy at ieast six weeks prior to month 
of pubiication to: Carole Porter, Classified 
Advertising, IEEE COMPUTER Magazine, 10662 
Los Vaqueros Circle, Los Alamitos, CA 90720. 


In order to conform to the Age Discrimination 
in Employment Act and to discourage age dis¬ 
crimination, IEEE COMPUTER may reject any 
advertisement containing any of these phrases 
or similar ones: "... recent college grads...," 
"...1-4 years maximum experience...,” 
"... up to 5 years experience...,” or “... 10 
years maximum experience.” IEEE COM¬ 
PUTER reserves the right to append to any 
advertisement, without specific notice to the 
advertiser, "Experience ranges are suggested 
minimum requirements, not maximums." IEEE 
COMPUTER assumes that, since advertisers 
have been notified of this policy in advance, 
they agree that any experience requirements, 
whether stated as ranges or otherwise, wili be 
construed by the reader as minimum require¬ 
ments only. 


WAYNE STATE UNIVERSITY 

The Computer Science Department invites ap- 
piications for severai tenure track or visiting 
positions at all levels. Applicants should have a 
Ph D. in Computer Science or a related 
discipline and show a strong commitment to 
research in an area of Computer Science. The 
saiaries wili be competitive and commensurate 
with the quaiifications of the candidates. 

Wayne State is one of the research universities 
in the State of Michigan. It is located in the 
cultural center of Detroit and serves the educa¬ 
tional needs of about 30,000 students. The Com¬ 
puter Science department has a full-time faculty 
of 17, offers B.S., M.S. and Ph.D. degrees, and 
has a current total of 190 graduate students (35 
Ph.D.). The current major areas of research in the 
department include database management 
systems, computer vision, distributed and 
parallel computing, software engineering, ar¬ 
tificial intelligence, and molecular computers. 
The department research facilities include ap¬ 
proximately 20 SUN and micro VAX worksta¬ 
tions, VAX 11/780, and COMPTALvision system, 
all interconnected by Ethernet. 

The university computing center operates an 
AMDAHL 470/V6, an AMDAHL 470/V8 and 
several microprocessor labs. The university 
computer systems are accessible via Telenet 
and Autonet, and are part of the MERIT network. 
There is a growing cooperation with research 
centers of the major automobile companies and 
other industrial organizations in the area. 

Send a Curriculum Vitae and the names, ad¬ 
dresses, and telephones of at least three 
referees to Dr. Horst F. Wedde, Search Commit¬ 
tee, Computer Science Department, Wayne 
State University, Detroit, Ml 48202; tel. (313) 
577-0731, 577-2477. 

Wayne State University is an Affirmative Ac¬ 
tion/Equal Opportunity Employer. We are par¬ 
ticularly interested in minority candidates. 


UNIVERSITY OF ALASKA-FAIRBANKS 

The Computer Science faculty invite applica¬ 
tions for anticipated tenure-track and visiting 
faculty positions, to be filled September, 1987, or 
January, 1988. Rank depends on qualifications. 
The University of Alaska-Fairbanks is the major 
research institution in the University of Alaska 
system and is the site of several world famous 
research institutes. The Department of Mathe¬ 
matical Sciences offers B.S. and M.S. degrees in 
Computer Science. The University facilities in¬ 
clude a research quality library and a statewide 
computer network of VAX 8800 and 8600 com¬ 
puters. In addition, the Department has a VAX 
11/780, PDF 11/23, several Masscomp color 
graphics work stations, and smaller computers. 
Applicants should have a Ph.D. In Computer 
Science or equivalent. Applicants with research 
interests in any field will be considered. Some 
preference will be given to applicants with exper¬ 
tise in operating systems, architecture, and hard¬ 
ware. Salary Is competitive and fringe benefits 
are excellent. Resume and three letters of 
reference should be directed to Dr. Clifton Lan- 
do. Head, Department of Mathematical Sci¬ 
ences, University of Alaska, Fairbanks AK 
99775-1110. Inquiries: (907) 474-7117 or 
FFBML@ALASKA.BITNET. Deadline for appli¬ 
cations: March 15, 1987. UAF is an Equal 
Opportunity/Affirmative Action employer and 
educational Institution. 


UNIVERSITY OF ALBERTA 
Department of Computing Science 

Applications are invited for a Faculty Service Of¬ 
ficer, which is a full time academic position, as 
DIRECTOR OF INSTRUCTIONAL LABORA¬ 
TORIES, in the Department of Computing 
Science. Responsibilities include the planning 
and supervision of instructional laboratories and 
the promotion of innovations in instructional 
methodology. Candidates should have con¬ 
siderable relevant academic experience: cur¬ 
riculum planning, teaching experience, course 
development and supervisory experience. An 
M.Sc is mandatory but a Ph.D. in Computing 
Science is preferred. Salary will be commen¬ 
surate with qualifications and experience; cur¬ 
rently salary floor is $39,620. Departmental in¬ 
structional laboratory facilities currently include 
four time-sharing terminal labs connected to the 
University Amdahl 5870 mainframe computer, 
three Macintosh PC Labs operated stand-alone 
or connected to the mainframe, a logic lab, and a 
micro-computer lab. A VAX 11/780 is largely 
devoted to several undergraduate courses, runn¬ 
ing under a UNIX operating system. Applica¬ 
tions, including a detailed resume and the 
names of three academic references should be 
submitted to: 

Dr. Lee J. White, Chairman 
Department of Computing Science 
University of Alberta 
Edmonton, Alberta T6G 2H1 
The closing date for applications is April 30,1987 
or earlier if a qualified candidate is found. The 
University of Alberta is an equal opportunity 
employer. 


UNIVERSITY OF WISCONSIN—MILWAUKEE 
Department of Electrical Egineering 
and Computer Science 

Applications are invited for faculty positions in 
Computer Science. Candidates should have a 
Ph.D. in Computer Science or a related disci¬ 
pline. A commitment to research and teaching is 
expected. Senior candidates should have a 
strong and established research record. Prefer¬ 
red areas are: programming languages, com¬ 
pilers, theory, systems, and artificial in¬ 
telligence. Research investigations by our cur¬ 
rent Computer Science faculty are in the areas of 
databases, data security, theory of computation, 
expert systems, computer architecture, parallel 
computation, and artificial intelligence. 

The University of Wisconsin—Milwaukee cam¬ 
pus is located near the shores of Lake Michigan 
and is close to pleasant and beautiful residential 
areas. Interested persons should send a resume 
with three references to: 

Professor K. Vairavan 
Chairperson—Computer Science 
Department of Electrical Engineering & 
Computer Science 
University of Wisconsin—Milwaukee 
P.O. Box 784 
Milwaukee, Wl 53201 


UNIVERSITY OF MASSACHUSETTS 

Faculty positions in Electrical and Computer 
Engineering. The Department of Electrical and 
Computer Engineering at the University of 
Massachusetts at Amherst is one of the largest 
in New England with 35 faculty and 275 graduate 
students. The Department Invites applications 
for tenure-track/tenured positions in: All areas of 
Computer Engineering. Already in place are 
strong programs In hardware, computer ar¬ 
chitecture, VLSI, and distributed processing. 
Computer facilities including CYBER 174 and 
175 machines together with a number of net¬ 
worked VAX 11/780, 11/785 and microVAX 
machines. The department is the recipient of 
substantial computing equipment for VLSI- 
related instruction from the Massachusetts 
Technology Park Corporation (MTPC) and has 
many ties with computer companies in the Com¬ 
monwealth providing research, equipment, con¬ 
sulting and teaching support. Candidates for 
senior positions are expected to have excellent 
research records and junior candidates must 
show strong research potential. All candidates 
must have interests in teaching as well as a 
strong research orientation. Teaching loads are 
generally conducive to the establishment or ex¬ 
pansion of high-quality research programs. At¬ 
tractive features of the University of Massachu¬ 
setts are the quality of life in the town of 
Amherst and the University’s proximity to the 
commonwealth’s high-technology Industry. 
Salaries are competitive and commensurate 
with experience. Send resume and names of 
three references to Professor Keith R. Carver, 
Head, Department of Electrical and Computer 
Engineering, University of Massachusetts, 
Amherst, MA 01003 by March 15, 1987. The 
University of Massachusetts is an Affirmative 
Action/Equal Opportunity Employer. 
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FACULTY-COMPUTER SCIENCE 
(Fall 1987) 

SUNY College of Technology at Utica/Rome 
seeks applications for 2-3 tenure track positions. 
Qualifications: Ph.D. in computer science or re¬ 
lated discipline required. Candidates with exper¬ 
tise in computerand systems architecture, infor¬ 
mation systems, programming languages and 
compiler design, real-time systems, and soft¬ 
ware engineering sought, but outstanding can¬ 
didates with other interests will be considered. 
Computer Science Department offers B.S. and 
M.S. degrees; currently has 12 full-time faculty, 
200 undergraduate and 40 graduate students 
(FTE). In addition to well-equipped computer 
center, the College of Technology has labora¬ 
tories dedicated to artificial intelligence, 
computer-aided design, computer vision, micro¬ 
processor development, telecommunications, 
and robotics. Proximity of college to USAF 
Rome Air Development Center and industrial 
and contract research facilities provides addi¬ 
tional opportunities for research and profes¬ 
sional development. 

College is located on new, 800-acre campus ad¬ 
jacent to Utica, a natural gateway to the Adiron¬ 
dack Mountains. Centrally located in New York 
State, Utica has been ranked among America’s 
top 25 most desirable metropolitan living areas. 
Applications accepted until March 31, 1987, or 
until positions are filled. Send vitae, three 
references to: 

Director of Personnel/AA 
Drawer 6017 

SUNY College of Technology at Utica/Rome 
Marcy Campus 
P.O. Box 3050 
Utica, NY 13504-3050 


SENIOR COMPUTER OPERATOR 

Manage data processing night shift. Perform ad¬ 
vanced computer operating activities according 
to procedures. Produce various department 
reports as needed. Responsible for maintenance 
of personnel, independent sales reps, financial 
and inventory control information. Must know 
IBM 360/40, 370/145 and 4341, DOSA/S, CICS, 
COBOL and Assembler programming; JCL, 
VSAM and other specific programs. Two years 
experience IBM 4300 series. Job site and inter¬ 
view Pasadena. $475 per week. Send this ad and 
your resume and letter stating your qualifica¬ 
tions to Job #MLU 7827, Box 9560, Sacramento, 
CA 95823-0560 not later than 3/6/87. 


THE UNIVERSITY OF TEXAS AT SAN ANTONIO 

Applications are invited for several tenure-track 
positions in computer science. We are seeking 
individuals who will contribute to the further de¬ 
velopment of our graduate program, particularly 
in the areas of architecture, graphics, data base, 
robotics, and scientific computing. Strong, in¬ 
dependent candidates who can interact with 
local research laboratories are encouraged to ap¬ 
ply. Appointment will be at the Assistant or 
Associate Professor level. A Ph.D. is required. 
Send vitae and three letters of recommendation 

Dr. David Eberly, Chairman 
Faculty Search Committee 
Division of Mathematics, Computer Science 
and Systems Design 
The University of Texas at San Antonio 
San Antonio, Texas 78285 
UTSA is an Affirmative Action Equal Opportunity 
Employer. 


DIRECTOR 

DIVISION OF MATHEMATICS 
COMPUTER SCIENCE AND 
SYSTEMS DESIGN 
THE UNIVERSITY OF TEXAS AT 
SAN ANTONIO 

The University of Texas at San Antonio invites 
applications and nominations for the position of 
Director. Division of Mathematics, Computer 
Science and Systems Design. The Division of¬ 
fers a wide range of programs in the computing 
and mathematical sciences at the undergradu¬ 
ate and master's level. The University of Texas at 
San Antonio admitted its first undergraduate 
class in 1975 and has since grown to 12,000 
students. The program has approximately 700 
majors and excellent potential for growth in its 
second decade. 

Candidates should have an earned doctorate in 
one of the disciplines encompassed in the divi¬ 
sion and should quality for a senior level 
academic appointment. Successful teaching ex¬ 
perience, demonstrated research record, and 
demonstrated potential for academic admini¬ 
strative responsibility are requisites forthe posi¬ 
tion. Preference will be given to candidates with 
some background in computer science. The 
salary will be commensurate with background 
and experience. 

Applications or nominations should include a 
vitae and the names of at least three references. 
Address inquiries and applications to: 
Chairperson, Search Committee for Director, 
MCSSD 

c/o Office of the Dean 
College of Sciences and Engineering 
The University of Texas at San Antonio 
San Antonio, Texas 78285 
Nominations and/or applications will be ac¬ 
cepted until March 15,1987 or until the position 
has been filled. The University of Texas at San 
Antonio is an Equal Opportunity/Affirmative Ac¬ 
tion Employer. 


COMPUTER SCIENTIST 

Responsible for design and development of ad¬ 
vanced interactive user interfaces for a system 
specification and verification environment. This 
includes constructing a menu-drive system and 
integrating it with windowing packages and the 
underlying system code on a variety of worksta¬ 
tions and operating systems. Requires M.S. 
degree in Computer Science and one year ex¬ 
perience in computer science or software 
engineering. Also requires experience with 
workstations, distributed systems, and network¬ 
ing; experience with a variety of operating 
systems and their user interfaces; and 
background in logic and non-procedural 
languages. Salary: $40,680 per year. Place of 
employement and interviews: Menlo Park, CA. 
Send this ad and a resume to Job #AW 10859, 
P.O. Box 9560, Sacramento, CA 95823-0560 not 
later than March 3, 1987. 


SYSTEMS ENGINEER 

This person will be responsible for all aspects of 
hardware and software design, implementation, 
testing, statistical analysis and determination of 
probability density function tor error rate analy¬ 
sis. Job and interview site: Carlsbad, California. 
Minimum Masters (EE) plus one year of relevant 
experience. Must be experienced in digital sig¬ 
nal processing and statistical analysis. Must 
have knowledge of Unix operating systems, “C” 
and Forth computer languages. Salary $36,000/ 
year. Send this ad and your resume to Job #CW 
10689, P.O. Box 9560, Sacramento, California 
95823-0560, not later than March 7, 1986. 


The Department of Computer Science 
at 

OREGON STATE UNIVERSITY 
and 

TEKTRONIX, INC. 
proudly announce the new 
Tektronix Graduate Fellowships 
in 

Computer Science 

We are pleased to announce that we anticipate 
that two new graduate fellowships in Computer 
Science at Oregon State University will be 
awarded, beginning with the fall quarter of 1987. 
These fellowships will carry a stipend of $10,000 
per year. 

Recipients will be selected on a competitive 
basis, with undergraduate performance, scores 
on the Graduate Record Examination, and 
references as the primary sources of informa¬ 
tion. We expect that recipients will enroll in the 
PhD program in Computer Science at OSU and 
will devote their full time toward the pursuit of 
that degree. 

For further information, and for application 
materials, please contact: 

Walter G. Rudd, Chairman 
Department of Computer Science 
Oregon State University 
Corvallis, Oregon 97331 
503-754-3273 
Rud@oregon-state 

Oregon State University is an Affirmative Ac¬ 
tion/Equal Opportunities employer and complies 
with Section 504 of the Rehabilitation Act of 
1973. 


FLORIDA INSTITUTE OF TECHNOLOGY 

The Department of Computer Science invites ap¬ 
plications for two positions at the Assistant Pro¬ 
fessor Level. Candidates must have a Ph.D. in 
Computer Science or a closely related field at 
the time of appointment. We are especially inter¬ 
ested in candidates with expertise in OS, Com¬ 
pilers, Al, Computer Architecture, Database 
Design, and Software Engineering, but others 
are encouraged to apply. Applicants should have 
demonstrated teaching effectiveness and show 
interest in research. Campus facilities include 
IBM and DEC systems and many micros. Each 
faculty member has his own micro and depart¬ 
ment facilities include five SUNs. FIT Is a 
science and engineering oriented university with 
about 175 undergraduate and 230 graduate stu¬ 
dents in CS and is located just south of Kennedy 
Space Center. Screening of applicants will begin 
February 1,1987. Please submit applications to 
Dr. Tom Hand, Department of Computer Sci¬ 
ence, Florida Institute of Technology, Mel¬ 
bourne, FL 32901. FIT is an equal opportunity, af¬ 
firmative action employer. 


UNIVERSITY OF THE DISTRICT OF COLUMBIA 
Computer Science 

The University invites applications for faculty 
positions in Computer Science. Ph.D. required 
tor associate and full professorships. Master's 
degree plus experience may be considered. 
Areas of specialization needed include: Com¬ 
piler Design and Theory, Digital Design, Com¬ 
puter Architecture, Microprocessor Applica¬ 
tions, and Data Structures. Salary and rank 
depend on qualifications. Submit complete 
resume to Ms. Christine Poole, Office of Per¬ 
sonnel, University of the District of Columbia, 
4200 Connecticut Avenue, N.W., Washington, 
DC 20008. An Equal Opportunity Employer. 
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SOUTHERN ILLINOIS UNIVERSITY 
AT CARBONDALE 

Senior/Junior Faculty Positions in the 
Computer Science Department 

Applications are Invited for four full time tenure 
track faculty positions in a growing, dynamic 
department, beginning August 15, 1987. 1. One 
position at the professor level: Candidates 
should have an established and substantial 
research record evidenced by scholarly publica¬ 
tions and external funding. The applicant would 
be expected to provide leadership in a newly 
developing doctoral program along with ex¬ 
cellence in teaching. 2. One position at the 
associate professor level: Applicants should 
have an established research record in a 
mainstream area of Computer Science, and 
would be expected to participate fully in the 
department's graduate program and provide ex¬ 
cellence in teaching. 3. Two positions at the 
assistant professor level: Candidates for these 
positions should demonstrate promise of on¬ 
going and future research as well as a commit¬ 
ment to teaching. Applications in ail areas of 
Computer Science will be considered, with the 
department specifically seeking expertise in the 
areas of programming languages and operating 
systems. Applications will be accepted until 
March 15, 1987 or until the positions are filled. 
Resumes should be sent to: Faculty Recruit¬ 
ment Committee, Department of Computer 
Science, Southern Illinois University, Carbon- 
dale, IL 62901. SlUC is an Equal Opportunity, Af¬ 
firmative Action Employer. 


TEXAS TECH UNIVERSITY 
Director, Computer Science 

The University has approximately 25,000 
students. At present, approximately 250 under¬ 
graduate and 30 graduate students are pursuing 
BS, MS, or PhD degrees in Computer Science. 
Additionally, undergraduate and graduate 
courses are offered to students from all other 
units of the University. 

The subject position reports directly to the Dean 
of the College of Engineering. The incumbent 
will be responsible for defining and pursuing a 
path of deveiopment and expansion that will 
result in the creation of a dynamic computer 
science education and research program consis¬ 
tent with the goals of the College of Engineering 
and the University. 

The preferred candidate will hold an earned doc¬ 
torate in Computer Science or closely related 
discipline, will have an established record of 
research productivity, and will be widely known 
and respected in the computer science com¬ 
munity. An undergraduate degree in engineering 
or substantial experience in an engineering field 
is a favorable factor. Applicants having leader¬ 
ship experience as well as teaching and 
research experience will be given preference. 
The successful candidate must hold credentials 
appropriate for appointment to the rank of full 
professor with tenure. 

Applications or nominations should be for¬ 
warded to: Dr. Edward E. Anderson, Chairman, 
Computer Science Director Search Committee, 
Texas Tech University, P.O. Box 4289, Lubbock, 
Texas 79409. 

Interested persons are urged to submit applica¬ 
tions before March 1, 1987. Applications will 
continue to be considered from that time until a 
candidate Is selected and appointed. 

Lubbock is a community of 200,000, located in 
the southwestern sunbelt, and serves a 100 
county area with a population exceeding 1.5 
million people. Its location makes it a regional 
center for education, transportation, medical 
care, cultural events, and retail marketing. 

Texas Tech University is an affirmative action/ 
equal opportunity employer. 


UNIVERSITY OF COLORADO AT DENVER 
Computer Science and Engineering 

Applications are invited for tenure-track faculty 
positions in Computer Science and Engineering. 
The Department of Electrical Engineering and 
Computer Science offers the B.S. and M.S. in 
Computer Science within the College of 
Engineering and Applied Science. The Ph.D. is 
offered through the multi-campus University of 
Colorado Graduate School. Applicants must 
have an earned doctorate in computer science or 
a related field, and a demonstrated record of ac- 
complishment in computer science and 
engineering. Our computer science student 
body is diverse and mature, with interests in ap¬ 
plied computer science and engineering. In¬ 
dividuals with Industrial as well as academic 
backgrounds will find our department a reward¬ 
ing environment for teaching and research. 
Present research interests in the department in¬ 
clude artificial intelligence, robotics, computer 
architecture, parallel computing, and software 
engineering. The department supports a VAX, 
Sun workstations, and numerous personal 
computers for faculty use. In addition, the 
department has access to a variety of main¬ 
frames, including a Cyber 205. The department 
encourages the development of sponsored 
research programs and scholarly publication 
through reduced teaching loads for new tenure- 
track faculty. For a qualified junior faculty 
member, the department also has an Amoco 
Foundation Engineering Faculty Grant, to sup¬ 
plement normal sources of funds for early career 
research, professional development, and 
associated activities. In early 1988 the depart¬ 
ment will move to a new 250,000 square foot 
building in downtown Denver, less than an 
hour’s drive from skiing and summer recreation 
along the Front Range of the Rocky Mountains. 
Applicants should submit a current vita and have 
at least four letters of reference sent to John 
Clark, Chairman, Department^f Electrical 
Engineering and Computer Science, University 
of Colorado at Denver, Campus Box 104, 1100 
Fourteenth Street, Denver, CO 80202. Non¬ 
citizens should identify the nature and status of 
their visas. Applications will be accepted until 
the positions are filled. The University of Col¬ 
orado at Denver is an Equal Opportunity/Affir¬ 
mative Action Employer. 


EMBRY-RIDDLE AERONAUTICAL UNIVERSITY 
Department of Computer Science 

Applications are invited for a full-time faculty po¬ 
sition in the Department of Computer Science. 
Ph.D. in Computer Science or in a closely related 
field with substantial computer science experi¬ 
ence Is required. Candidates should have a 
strong commitment to teaching. Rank will be 
commensurate with qualifications and experi¬ 
ence, and salary will be competitive. 

The department offers a B.S. in Computer 
Science, and currently has about 250 Computer 
Science majors. Facilities include an IBM 4361, 
numerous microcomputers, a microprocessor 
lab and a graphics lab. Faculty are encouraged to 
develop research programs. Daytona Beach en¬ 
joys the best of Florida weather all year round, 
and the University itself is located three miles 
from the beach. 

Applicants should submit a resume and the 
names of three references to: Chair of the Facul¬ 
ty Search Committee, c/o The Office of Person¬ 
nel, Embry-Riddle Aeronautical University, 
Regional Airport, Daytona Beach, Florida, 32014. 
ERAU is an equal opportunity employer. 


SOFTWARE DEVELOPMENT 

Section Manager, Software Development. 
Manage software engineers to develop user in¬ 
terface software. Monitors/supervises and pro¬ 
vides technical support to projects. Develop 
query/natural languages, database and com¬ 
mand interface products. 20-50% of job consists 
of design/develop/implement fourth generation 
languages. Delivers presentations regarding 
special projects. Liaises with all levels staff/up¬ 
per management. Requires: B.S. Computer 
Science (or bulk of program). 3 years experience 
in job or 5-6 years experience in Com¬ 
puter/Business applications development (with 
minimum two years as Project Manager). Have 
depth experience with REALITY/PICK 0/S. 
Strength in DATA/BASIC/PROC and know REAL 
languages. Experience in all PRO-IV a plus. Need 
exceptional knowledge of fourth generation 
languages and application development tools of 
systems. $41K per year. Job Site: Irvine, CA. 
Send this ad and your resume to Job #CW 10519, 
P.O. Box 9560, Sacramento, CA 95823-0560, no 
later than March 9, 1987. 


UNIVERSITY OF LOWELL 
Department Head 

The University invites applications for the posi¬ 
tion of Computer Science Department Head. The 
Department Head exercises the primary leader¬ 
ship role within the Department, is responsible 
for interfacing with external professional and in¬ 
dustrial organizations in computer science 
related fields, administers academic programs, 
recruits and evaluates faculty, develops a com¬ 
prehensive departmental research plan, and 
manages department resources. 

The successful candidate must hold an earned 
doctorate in computer science or related field, 
satisfy requirements for appointment as tenured 
professor and evidence a strong record of 
research, and grants and contracts with govern- 
mentai and industriai sponsors. 

The University of Lowell, located in the center of 
the high-technology corridor northwest of 
Boston, Is one of three public universities in 
Massachusetts. With a current enrollment of 
over 15,000, its entering students have the 
highest composite SAT scores among Massa¬ 
chusetts public colleges. Now in its seventh 
year, the Department of Computer Science (23 
full and 10 part-time faculty) enrolls 500 
undergraduates, 250 M.S. students, and 20 Sc.D. 
candidates and has recently relocated to a new 
facility (37,000 sq. ft.). Department hardware 
resources include three DEC VAX’s, two Micro- 
VAX’s, three DG MV’s, two Symbolics 3600’s, a 
Ridge-32, 12 Apollo nodes and a Sequent 
Balance 21000 multiprocessor system. Systems 
are linked by Ethernet facilities within the 
Department and a broadband to other University 
resources. External access Is provided by 
CSNET and USENET. A primary contributor to 
the University’s Center for Productivity Enhance¬ 
ment and a Massachusetts Microelectronics 
Center’s VLSI CAD fabrication network, the 
Department engages in a broad spectrum of 
theoretical and applied research, including 
graphics, robotics, Al, SWEng, and CAI. 

The search will remain open through March 1987 
or until position filled. Interested applicants, 
please submit complete professional resume, a 
list of three references (with addresses) and a let¬ 
ter of application to: Dr. Robert Lechner, Chair¬ 
man, Search Committee, Department of Com¬ 
puter Science, University of Lowell, Lowell, MA 
01854. 

The University of Lowell is an Equai Oppor¬ 
tunity/Affirmative Action, Title IX, 504 Employer. 
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THE UNIVERSITY OF TENNESSEE 
Department of Computer Science 

The Department of Computer Science invites ap¬ 
plications for tenure track and visiting positions 
at aii ranks beginning Winter of 1987. A doctoral 
degree in computer science or a related area, 
and a strong interest in research are required. All 
areas of computer science research will be con¬ 
sidered. Those with experience directing doctor¬ 
al students are especially encouraged to apply. 
The department operates a research laboratory, 
which contains two DEC VAX 8200’s (one VMS, 
one UNIX) and a variety of microcomputers. Each 
faculty member has for a personal workstation 
an IBM PC AT, a Sun, or a MicroVAX II. Special¬ 
ized laboratories support research in areas of 
special emphasis. The University of Tennessee 
Computing Center operates an IBM 3081, an IBM 
4381, and four VAX 8600’s. Faculty members col¬ 
laborate with scientists at the Oak Ridge Na¬ 
tional Laboratory and frequently have access to 
their facilities, including a Cray X-MP and hyper¬ 
cube computers, under the terms of the col¬ 
laboration. Faculty workstations are networked 
with the departmental laboratories, the Universi¬ 
ty Computing Center, and facilities at the Oak 
Ridge National Laboratory. 

You can respond on CSNET with cset:straight@ 
utenn and on BITNET with bitnetistraight® 
utkvxl. The mailing address is Computer 
Science Department, 107 Ayres Hall, University 
of Tennessee, Knoxville, TN 37996-1301. 

The University of Tennessee is an affirmative ac¬ 
tion/equal opportunity employer. 


PROGRAMMER/ANALYST 

Design and development of NCR mainframe 
computer software. Requires at least four years 
of experience with NCR software programming. 
$33,000/year. 40 hours/week. 9 a.m. to 5 p.m. Job 
site; Pacheco, California. Send this ad and a 
resume to Job #MLU 10588, PO Box 9560, 
Sacramento, CA 95823-0560 not later than March 
2, 1987. 


UNIVERSITY OF MARYLAND 
Institute for Advanced Computer Studies 

The University of Maryland Institute for Advanced 
Computer Studies (UMIACS) was established in 
1985 by Maryland Governor Harry Hughes. 
UMIACS, while residing on the College Park 
campus, is intended to serve the entire Universi¬ 
ty of Maryland system as a focal point for 
research activities in computing. 

UMIACS currently has 20 tenure track research 
faculty lines, in addition to a substantial 
operating budget to support the research ac¬ 
tivities of its faculty. Within three years, UMIACS 
will grow to 30 research faculty lines. Most facul¬ 
ty members in UMIACS will hold joint appoint¬ 
ments with academic departments on the cam¬ 
pus; their teaching responsibilities would be 
reduced according to their percentage appoint¬ 
ments in UMIACS. 

Several faculty positions have been reserved for 
permanent, full-time appointments in the Insti¬ 
tute. These appointments will be 12 month ap¬ 
pointments for senior level faculty and will include 
commitments from the Institute for research 
support (e.g., equipment, travel, graduate 
students, etc.). Applicants for these permanent 
positions should send a complete resume and 
names of four references to Prof. Larry S. Davis, 
Acting Director, University of Maryland Institute 
for Advanced Computer Studies, College Park, 
MD 20742. The University of Maryland is an equal 
opportunity and affirmative action employer. 
Women and minorities are encouraged to apply. 


MICHIGAN STATE UNIVERSITY 

The Department of Computer Science invites ap¬ 
plications for tenure track positions at all levels. 
Candidates from all areas of specialization in 
computer science or computer engineering will 
be considered. The department has a special in¬ 
terest in candidates in the areas of programming 
languages, database systems, artificial in¬ 
telligence and expert systems, robotics, design 
of computer systems and networks, parallel 
computation, dataflow machines, operating sys¬ 
tems and computational complexity. Candidates 
should have a Ph.D. in computer science or com¬ 
puter engineering and have a strong interest in 
both research and teaching. Applications will be 
accepted until the positions are filled. 

As a unit within the College of Engineering at 
Michigan State University, Computer Science of¬ 
fers the Bachelor of Science, Master of Science 
and Doctor of Philosophy degrees. Special sup¬ 
port is available from within the college and 
university to initiate research by new faculty 
members. Faculty offices are connected to the 
MSUnet which provides access to an array of 
campus computing resources including the 
facilities of the College of Engineering, the 
Department’s VAX 8600, and Department’s 
Distributed Computing Research Laboratory 
with SUN-2 and SUN-3 workstations. Access to 
select off-campus computers is available, as 
well as access to ARPANET, CSNET, BITNET, 
and MAILNET. Additional facilities available to 
faculty are the Department’s Pattern Recogni¬ 
tion and Image Processing Laboratory and the 
College’s A.H. Case Center for Computer-Aided 
Design. 

Michigan State University enjoys a park-like 
campus of 2,100 developed acres and 3,100 
acres of experimental farms, outlying research 
facilities and natural areas. The campus is adja¬ 
cent to the cities of East Lansing and the capital 
city, Lansing. The Greater Lansing area has ap¬ 
proximately 250,000 residents. The communities 
have fine school systems and place a high value 
on education. 

Applicants should send a resume and a state¬ 
ment of research and teaching interests to; Dr. 
Anthony S. Wojcik, Chairperson, Department of 
Computer Science, A714 Wells Hall, Michigan 
State University, East Lansing, Michigan 
48824-1027. CSNET wojcik@mich-state.csnet. 
Michigan State University is an Equal Oppor¬ 
tunity/Affirmative Action Institution and en¬ 
courages applications from members of ethnic 
minority groups. 


PROGRAMMER/ANALYST II 

Programmer/Analyst II for Program in Com¬ 
puting, Math Department. Design, develop, pro¬ 
gram, install and document new systems and ap¬ 
plications software for system administration. 
Modify, debug and document existing software. 
Assist in installation of operating system up¬ 
dates and hardware. Consult with users and train 
faculty and staff. 

Requirements; B.A. or B.S. in Math/CS or related 
field, one year of experience as computer pro¬ 
grammer; kernel level knowledge of UNIX and 
PC/DOS operating systems. Ability to write com¬ 
plex programs in C and Pascal; working knowl¬ 
edge of FORTRAN; ability to write Shell scripts. 
Understanding of networking and hardware con¬ 
cepts. Ability to clearly present alternative solu¬ 
tions to complex problems in both written and 
oral form. Demonstrated ability to work with 
users at all levels of computer expertise. 

Job location; Los Angeles, CA $28,500/yr. 40 
hrs/week. 

Send this ad and resume to Job #mlu#10092, 
P.O. Box 9560, Sacramento, CA 95823-0560 no 
later than March 1, 1987. 


UNIVERSITY OF MISSOURI—KANSAS CITY 

1986 was another stellar year. Besides two 
regular faculty additions, three technical support 
positions were filled, a dual processor ELXSI and 
120 micros were installed and we moved to a 
larger site. If you want to join this burgeoning 
program and your research activities are in 
Telecommunications, Computer Networking, Ar¬ 
tificial Intelligence or a field closely related to 
one of these three, we would like to hear from 

Nine- or twelve-month appointments at all ranks 
are available at industry-competitive salaries. 
Research productivity is required so time for 
research is guaranteed in proportion to your per¬ 
formance. An agreement with United Telecom, 
Inc. provides up to one-half million dollars an¬ 
nually of “inhouse" research support for faculty 
and graduate students. A second multimillion 
dollar contract for research is nearing comple¬ 
tion and will provide significant additional fund¬ 
ing in the areas of computer networking and 
telecommunications. Our two year old program 
is still gaining momentum and you could add to 
the excitement. 

Call or write; Dr. Richard G. Hetherington, Direc¬ 
tor, Computer Science, 16 Cockefair Hall, Univer¬ 
sity of Missouri-Kansas City, 5100 Rockhill 
Road, Kansas City, MO 64110. (816) 276-1193 (by 
Apri 115 tor Fal I semester appt.; by October 15 tor 
Spring semester appt). UMKC is an Equal Oppor¬ 
tunity/Affirmative Action Employer. 


UNIVERSITY OF CALIFORNIA, DAVIS 
Faculty Positions in Electrical and Computer 
Engineering/Computer Science 

The Department of Electrical and Computer 
Engineering at UC Davis invites applications for 
tenure track positions at all ranks in all special¬ 
ties of electrical engineering, computer engi¬ 
neering, and computer science. Of particular 
interest are faculty positions in the areas of in¬ 
tegrated optics and opto-electronics, computer 
architectures, artificial intelligence, computer 
communications, and image processing. 

The department, with 40 faculty members and 
150 full-time graduate students, is experiencing 
rapid growth. Our College is the nation’s six¬ 
teenth largest producer of engineering Ph.D.’s in 
a University which has the twentieth largest ex¬ 
tramural research funding. Salary and benefits 
are extremely attractive. 

Davis is a pleasant, family oriented community, 
within easy driving distance to Silicon Valley, 
the Lawrence Livermore National Laboratory, 
San Francisco, the Pacific Ocean, and the Sierra 
Nevada Mountains. 

We are seeking individuals with strong records 
of teaching and research with ambitious plans. 
Senior appointments require outstanding 
records of achievement; junior appointments 
must show evidence of great promise. All faculty 
are expected to have a strong commitment to 
teaching at all degree levels, and to demonstrate 
the ability to attract significant research support. 
The positions require a Ph.D. degree or 
equivalent, and are open until filled. Send a 
resume and the names of at least three 
references to; 

Professor S. Louis Hakimi, Chair 
Department of Electrical and 
Computer Engineering 
University of California 
Davis, CA 95616 

The University of California, Davis, is an equal 
opportunity/affirmative action employer. 
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FLORIDA STATE UNIVERSITY DUKE UNIVERSITY 

Department of Computer Science Department of Computer Science 


Applications are invited for tenure track faculty 
positions at all levels in the Department of Com¬ 
puter Science starting August, 1987. Areas of 
special interest include, but are not limited to, 
operating systems, programming languages, 
computer graphics, software engineering, and 
computer architecture. 

Our department is a young and rapidly growing 
one. It offers B.S., M.S., and Ph.D. degrees, and it 
places a strong emphasis on excellence in 
research and teaching. Research facilities in¬ 
clude a supercomputer CYBER 205, a CYBER 
760, CYBER 730s, a graphics lab, and a local net¬ 
work consisting of a VAX 11/780, a VAX 11/750, 
several SUN workstations, and Symbolics 3640. 
Applicants should have a Ph.D. in computer 
science or a closely related area, and a strong 
commitment to research and teaching. 

Send resume and names of at least three profes¬ 
sional references to: Dr. Abe Kandel, Chairman, 
Department of Computer Science, Florida State 
University, Tallahassee, FL 32306-4019. 

Florida State University Is An Equal Opportunity 
Affirmative Action Employer. 


UNIVERSITY OF HOUSTON 
Applications are invited for tenure track faculty 
positions in the Department of Computer 
Science starting September 1987. Areas of 
special interest include but are not limited to ar¬ 
tificial intelligence, computer architecture, 
operating systems, programming languages and 
software engineering. Rank and salary are open 
and competitive. The Department is interested in 
expanding its research program and particularly 
welcome applicants for senior positions. Ap¬ 
plicants should have Ph.D. in Computer 
Science or a closely related area, and a strong 
commitment to research and teaching. Can¬ 
didates for senior positions should also have a 
distinguished research record. The Department 
offers Ph.D., M.S., and B.S. in Computer Science. 
Departmental research facilities include a net¬ 
work of VAX 11/780 and VAX 11/730’s, a network 
of AT&T 3B20 and 3B2’s along with access to 
other computer facilities in the University Com¬ 
puter Center as well as supercomputers via 
remote access terminals. Send resume and 
names of professional references to Dr. Willis K. 
King, Chairman, Department of Computer 
Science, University of Houston, Houston, Texas 
77004. An Equal Opportunity/Affirmative Action 
Employer. 


RUTGERS UNIVERSITY 
Computer Engineering 

Rutgers University has openings for tenure-track 
faculty in its newly organized Computer 
Engineering Program. Applicants with 
specialization in software engineering, VLSI 
design and testing, computer graphics, image 
processing, computer architecture and parallel 
processing are of particular interest. Excellent 
computer and research laboratory facilities are 
available. Teaching loads are modest and reflect 
the university’s objective of building a program 
with excellence in teaching and research. Ap¬ 
plicants are expected to have a strong commit¬ 
ment to both research and teaching. Interested 
individuals should send a resume and the names 
of four references to 
Professor Herbert Freeman 
Computer Engineering Program 
Rutgers University 
P.O. Box 909 
Piscataway, NJ 08854 

Rutgers is an equal-opportunity, affirmative- 
action employer. 


The Duke University Department of Computer 
Science, a 1983 recipient of an NSF CER Grant, 
has faculty positions available at all ranks. Ap¬ 
plications are solicited from all areas of com¬ 
puter science. Applicants for senior positions 
must demonstrate excellence in research, while 
applicants for junior positions must exhibit the 
promise of excellence. 

The Department currently has seventeen tenure 
track faculty, approximately 300 undergraduate 
majors and 50 graduate students pursuing 
master’s and/or doctoral degrees. 

The Department has major research efforts in 
scientific computing with emphasis on numeri¬ 
cal linear algebra, the solution of PDEs, and VLSI 
simulation: computer systems with emphasis on 
computer architectures, modeling of fault- 
tolerant systems, systems performance, and 
communications; artificial intelligence, par¬ 
ticularly in the areas of natural language inter¬ 
face, search methodologies, and expert sys¬ 
tems; and theory and algorithms with emphasis 
on combinatorial and graph-theoretic studies. 
Special motivation tor the research efforts 
comes from the areas of medical applications (in 
collaboration with the Duke Medical Center), and 
VLSI (in collaboration with the Microelectronics 
Center of North Carolina, of which Duke is a Par¬ 
ticipating Institution). 

Interested applicants should send copies of 
their resumes and other supporting material to 
Professor Donald J. Rose 
Department of Computer Science 
Duke University 
Durham, NC 27706 

Duke University is an affirmative action, equal 
opportunity employer. 


CALIFORNIA STATE UNIVERSITY 
Dominguez Hills 

The Department of Computer Science invites ap¬ 
plications for one tenure-track position with ap¬ 
pointment rank and salary step open. The ap¬ 
pointment is effective 24 August 1987. 

A Ph.D. in Computer Science or a closely related 
field is required. Other qualifications are a com¬ 
mitment to quality teaching and competence in 
research with publication in computer science 
or related field. Duties include teaching all 
undergraduate ACM core courses, student ad¬ 
vising, university committee work, curriculum 
development and scholarly activity. Normal 
teaching loads are 12 units per semester. 
Specialties in the areas of software engineering, 
data engineering or machine architecture are 
desired, but all areas will be considered. 
University computing facilities include a CDC 
Cyber 170/730, a Prime 9750 and.microcomputer 
labs and classrooms. Departmental systems in¬ 
clude a DEC PDP 11/24, an Altos 8600 and an 
AT&T 3B5/201. The department offers a BSc in 
computer science and enrolls 1000 students per 
semester including extensive evening classes. 
Design efforts for a proposed MSc in computer 
science are proceeding. The department has 
seven full-time and 20 part-time and adjunct 
faculty. Excellent consulting opportunities are 
available at numerous nearby aerospace firms. 
Qualified applicants should send a letter of ap¬ 
plication with resume and three letters of recom¬ 
mendation by 15 March 1987 to: Dr. Frank A. 
Chimenti, Chair, Computer Science Dept., 
California State University, Dominquez Hills, 
1000 East Victoria Street, Carson, CA 90747. 
CSUDH is an equal opportunity, affirmative ac¬ 
tion employer. 


WRIGHT STATE UNIVERSITY 
Computer Science & Engineering 

Applicants are invited for full-time positions in 
Computer Science and/or Computer Engineer¬ 
ing at all faculty levels. There is particular in¬ 
terest in professors who have sufficient experi¬ 
ence, currency, and depth to direct doctoral 
students and research dissertations in a PhD 
program in Computer Science & Engineering. 
The Department is also interested in PhD’s with 
less experience, but who have a commitment to 
research and teaching in a PhD granting pro¬ 
gram. Rank and competitive salaries are deter¬ 
mined by qualifications and experience. 

The State supported university is located in a 
high technology environment among industrial/ 
military research and development facilities. An 
associated State assisted research park to fos¬ 
ter basic and applied industrial/military/Univer- 
sity research is active and growing impressively. 
The University has identified Computer Science 
& Computer Engineering an area of highest prior¬ 
ity for continued development. 

Department strengths include a large faculty, ex¬ 
tensive laboratory facilities, research programs, 
industrial/military support, degree programs in 
both computer science and computer engineer¬ 
ing, and large student populations at graduate as 
well as undergraduate levels. 

Successful candidates for tenure-track posi¬ 
tions should have a Ph.D. in Computer Science, 
Computer Engineering, or equivalent back¬ 
ground, and have demonstrated a strong re¬ 
search, as well as teaching, commitment. Any 
non-tenure-track positions will be filled by can¬ 
didates with strong Computer Science or Com¬ 
puter Engineering credentials. At least a Master 
of Science Degree in the field is desired. 

Please submit detailed resumes including 
names of 3 references to: Professor Larry A. 
Crum, Chair, Department of Computer Science, 
Wright State University, Dayton, Ohio 45435. 
Reviewing for tenure-track positions will begin 
December 1,1986 and for non-tenure-track posi¬ 
tions on March 1,1987. Reviewing will continue 
monthly until positions are filled or until 
September 1, 1987. 

An equal opportunity/affirmative action 
employer. 


UNIVERSITY OF CALIFORNIA 
SANTA BARBARA 

Electrical and Computer Engineering 

Applications are invited tor three tenure track 
faculty positions in computer engineering. One 
position is in the area of design automation 
(CAD tools, techniques, algorithms, or expert 
systems) to support and/or validate VLSI-based 
designs. The remaining positions may be filled 
from any specialty within computer engineering, 
with preference given to applicants experienced 
in the fields of parallel computing, very high¬ 
speed digital circuit design/analysis, or fault- 
tolerant computing. The positions start at the 
rank of Assistant Professor, although higher 
level appointments are possible for individuals 
with outstanding records. Normally, completion 
of a doctorate is required at the time of the ap¬ 
pointment. Candidates should have an outstand¬ 
ing research potential or a distinguished re¬ 
search reputation, the ability to attract external 
research funding, and a strong commitment to 
teaching at the undergraduate and graduate 
levels. Applicants should send their resume, 
copies of recent publications, and the names of 
at least four professional references to: Chair¬ 
man, Computer Engineering Faculty Search 
Committee, Electrical and Computer Engineer¬ 
ing, University of California, Santa Barbara, CA 
93106, (805) 961-3821. Applications will be re¬ 
ceived until the positions are filled. An Equal Op¬ 
portunity/Affirmative Action employer. 
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THE GEORGIA INSTITUTE OF TECHNOLOGY 
Director, School of Information 
and Computer Science 

The Georgia Institute of Technoiogy invites ap- 
piications for the position of Director of the 
Schooi of Information and Computer Science, ef¬ 
fective Juiy 1, 1987. This position aiso includes 
appointment at the rank of Fuil Professor in the 
School. Qualified persons with outstanding 
records of achievement in research and teaching 
are encouraged to appiy. 

The Schooi of information and Computer 
Science is one of the iargest on the GeorgiaTech 
campus. The Schooi inciudes a staff of 28 aca¬ 
demic facuity, 10 research facuity, 16 profes- 
sionai staff members, 80 Ph.D. students, 150 
students enrolied in the M.S. program and ap- 
proximateiy 500 undergraduate majors enroiled 
in the CSAB accredited B.S. program. Sponsored 
research represents over haif of the Schooi’s 
yeariy budget, with major research programs in 
software engineering, artificiai inteliigence, 
distributed computing and computer networks. 
Aii of the school’s research is supported by weil- 
equipped iaboratories. In 1988, the School will 
move into a new building which will provide ex¬ 
cellent research and teaching facilities. 

Georgia Tech is a technological university of ap¬ 
proximately 11,000 graduate and undergraduate 
students located on a pleasant campus that is 
only a short walk from downtown Atlanta. As a 
result of its selective admissions. Tech students 
are of exceptional quality. GeorgiaTech has the 
highest percentage of National Merit Scholars of 
any publicly supported university in the nation. 
Institute priorities include the continued expan¬ 
sion and improvement of Ph.D. programs, espe¬ 
cially in Information and Computer Science. 

The Atlanta area offers superior cultural and 
recreational opportunities, a rapidly growing 
base of technological companies, and the sec¬ 
ond busiest airport in the world, which makes air 
travel very convenient. The Atlanta metropolitan 
area of two million people provides some of the 
most beautiful residential areas at reasonable 
prices to be found anywhere in the country. 
Nominations and applications should be sent to; 
Richard A. DeMillo, Chairman, ICS Director 
Search Committee, School of Information and 
Computer Science, Georgia Institute of 
Technology, Atlanta, Georgia 30332-0280. 

The closing date for applications is April 15, 
1987. Georgia Tech is a unit of the University 
System of Georgia and is an Equal Oppor¬ 
tunity/Affirmative Action Employer. 


EASTERN WASHINGTON UNIVERSITY 

The Computer Science Department of Eastern 
Washington University invites applications for 
an Associate Professor position in computer sci¬ 
ence beginning September, 1987. Tenure track 
for qualified candidate. Salary commensurate 
with qualifications and experience. A good fr¬ 
inge benefit package is provided. A Ph.D. or 
equivalent in computer science or a related field 
is preferred. Industrial experience will be con¬ 
sidered. Non-U.S. citizens please state visa 
status. Duties include teaching undergraduate 
and graduate level courses, carrying out re¬ 
search or other creative activity, and curriculum 
development. Facilities for academic computing 
include two networked VAX-11/780 computers 
running VMS and Eunice, a PDP-11/24, and 
numerous microcomputers. Send letter of ap¬ 
plication, resume and the names of three recom¬ 
mendations to: Dr. S.F. Robinson, Computer 
Science Dept., MS#86, Eastern Washington 
University, Cheney, WA 99004. AA/EOE 


DePAUL UNIVERSITY 
CHICAGO, IL 

Positions in Computer Science 

DePaul University invites applications tor a 
tenure-track position in Computer Science at 
any level. The starting date is September 1987. 
Any area of specialization will be considered. An 
applicant should hold a Ph.D. in Computer 
Science or be a candidate for such a degree. 
Consideration will also be given to holders of 
Ph.D. degrees in Mathematics or related fields 
who have an interest in changing fields to Com¬ 
puter Science. Duties include a six-hour 
teaching load, advising, and research. Tenure 
details and salary are negotiable. Benefits in¬ 
clude TIAA and standard health insurance. U.S. 
citizenship is not required. 

The Department of Computer Science and Infor¬ 
mation Systems has over 400 undergraduate ma¬ 
jors and over 650 graduate majors. Facilities in¬ 
clude two VAX 11/780’s, a VAX 11/750, an IBM 
4381, an AT&T 3B15, three PDP11 ’s, a Harris 800, 
a number of Al workstations including two Sym¬ 
bolics, and numerous LSI-11’s and microcom¬ 
puters. The Department has an Artificial In¬ 
telligence Laboratory and a Vision Laboratory 
and is in the process of equipping a Telecom¬ 
munication and Data Communication Laborato¬ 
ry. There are also numerous PC Laboratories. 
Faculty interests include artificial intelligence, 
computer vision, applied statistics, applied 
graph theory, information systems, compiler de¬ 
sign, semantics of programming languages, and 
computer architecture. 

Applications will be received until positons are 
filled. To apply, send a resume and at least three 
letters of reference to; Gerald Gordon, Chairman, 
Faculty Recruitment Committee, Department of 
Computer Science and Information Systems, 
DePaul University, 243 S. Wabash Avenue, 
Chicago, IL 60604. 

DePaul University is an equal opportunity 
employer. 


UNIVERSITY OF CALII^ORNIA, IRVINE 
Department of Electrical Engineering 

The Department of Electrical Engineering at the 
University of California, Irvine, invites outstand¬ 
ing individuals to apply for tenure track positions 
at all levels in the area of computer engineering. 
The levels of these appointments may be at As¬ 
sistant Professor, Associate Professor, or Pro¬ 
fessor depending on accomplishments and 
stature in the field. Subareas of special interest 
include, but are not limited to 

1. parallel structured architectures 

2. artificial intelligence 

3. software engineering 

4. computer graphics 

Responsibilities include research and teaching 
at the graduate and undergraduate levels. 

The Department has research activities in fault- 
tolerant computing, design automation, distri¬ 
buted computing, and real-time computing, and 
in closely related areas including digital signal 
processing, image processing, pattern recogni¬ 
tion, robotics, digital communication, and com¬ 
munication networks. The Department currently 
has 19 faculty members, two of which are mem¬ 
bers of the National Academy of Engineering 
and seven Fellows of the IEEE. 

Send your complete resume with three refer¬ 
ences to Professor Jack Sklansky, Chairman of 
the Computer Engineering Faculty Search Com¬ 
mittee, Department of Electrical Engineering, 
University of California, Irvine, California 92717. 
The University of California is an affirmative ao- 
tion/equal opportunity employer. To ensure con¬ 
sideration, apply before March 15,1987. 


UNIVERSITY OF DELAWARE 
Department of Computer and 
Information Sciences 

Are you interested in joining the computer 
science faculty of a growing, dynamic depart¬ 
ment in an attractive university town within easy 
traveling distance to New York, Philadelphia, 
Baltimore, and Washington? The University of 
Delaware, centrally located on the East Coast, is 
recruiting for possible openings for tenure-track 
and visiting faculty positions in the Department 
of Computer and Information Sciences. Strong 
applicants in all areas of computer science are 
encouraged to apply. Special interest exists for 
candidates with research expertise in artificial 
intelligence, languages and architectures for 
parallel processing, networking, symbolic com¬ 
putation, graphics, data base systems, theoreti¬ 
cal computer science, and software engineering. 
A Ph.D. degree or its equivalent, and excellence 
in research and teaching are required. Salary and 
rank will be commensurate with the candidate’s 
qualifications and experience. 

The Computer and Information Sciences Depart¬ 
ment offers bachelor, master, and doctoral 
degrees. Resources devoted to academic use in 
the University Computing Center include: an 
IBM 3081D, a CDC Cyber 174, a Vax 8600 and 
Pyramid 98xe both running Unix, and more than 
75 microcomputers (IBM PC-XT’s, AT’s and 
Macintosh’s). 

The Department research facilities include 
various workstations (Symbolics Lisp machine, 
Micro-Vax II, SUN-3’s, IBM-AT’s and HP 9836A’s) 
and facilities in a joint research lab shared with 
the Department of Electrical Engineering. The 
latter includes a VAX-8500, two VAX 780’s and 
various other smaller machines. The equipment 
is connected to the ARPAnet, CSNet and to 
BITNET. 

Candidates should send a curriculum vitae and 
the names of three references to Professor B. F. 
Caviness, Department of Computer and Informa¬ 
tion Sciences, University of Delaware, Newark, 
DE 19716. 

The University of Delaware is an equal opportuni¬ 
ty, affirmative action employer. Applications 
from members of minority groups and women 
are encouraged. 


UNIVERSITY OF MINNESOTA 
Computer Engineering Faculty 

University of Minnesota, Duluth has several 
tenure and tenure-track (associate professor or 
professor) positions available. Primarily teach 
upper division computer hardware courses, con¬ 
duct sponsored research. Eligible candidates 
have Ph.D. with teaching/industrial experience. 
Write or call for details. Computer Engineering 
Department, UMD, Duluth, MN 55812. (218) 
726-6147. The University of Minnesota is an 
equal opportunity educator and employer and 
specifically invites and encourages applications 
from women and minorities. 


COMPUTER PROGRAMMER ANALYST 

Analyze business procedures and problems to 
refine and convert data to programmable form 
for electronic processing. Study existing data 
handling system and develop improvements. 
Confer with department management to deter¬ 
mine output requirements and data breakdown 
for reports. Must be knowledgeable in use of 
IBM System 38 and RPG III and CLP languages. 
Four years experience required. $35,000 per year. 
Job site and interview Costa Mesa, CA. Send this 
ad and resume to Job #CW10511, P.O. Box 9560, 
Sacramento, CA 95823-0560 no later than 3/2/87. 
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MISSISSIPPI STATE UNIVERSITY 


WORCESTER POLYTECHNIC INSTITUTE 
Head of the Computer Science Department 

Worcester Polytechnic Institute invites applica¬ 
tions and nominations for the position of Head 
of the Computer Science Department. The In¬ 
stitute seeks an individual who can provide in¬ 
novative and dynamic leadership of its educa¬ 
tional and research programs. This outstanding 
scientist and educator should have an earned 
doctorate and a distinguished record of research 
and scholarly achievement, as well as demon¬ 
strated leadership in one of the component 
specializations of Computer Science. In addition 
to administrative responsibilities, the depart¬ 
ment head will be charged with strengthening 
overall program quality and fostering scholarly 
excellence, in cooperation with other depart¬ 
ments, government and industry. 

There are 15 full time equivalent CS faculty, 260 
undergraduates, and 50 graduate students. 
Degrees are offered at the B.S., M.S., and Ph.D. 
levels. The WPI plan, a project oriented cur¬ 
riculum, forms the basis of a unique and suc¬ 
cessful undergraduate program that has been 
accredited by the Computer Science Accredita¬ 
tion Commission of the Computing Sciences 
Accreditation Board. Department laboratories 
contain three VAX 750’s, twenty PDP 11’s, a DG 
MV/8000, and an IBM Series/1 with 35 PC’s, con¬ 
nected by Ethernets. The college is committed 
to the construction of a new Information 
Sciences building. Located near Boston, in the 
center of the computer industry, Worcester has 
eight universities and colleges, and offers a rich 
variety of professional and cultural activities. 
Nominations and applications, including cur¬ 
riculum vitae and the names of three references, 
will be accepted until March 15, 1987 or until a 
suitable candidate is found. 

Please respond to: 

Professor Robert A. Peura, Chairman, Computer 
Science Search Committee, Worcester 
Polytechnic Institute, Worcester, MA 01609. An 
Equal Opportunity/Affirmative Action Employer. 


UNIVERSITY OF TENNESSEE 
SPACE INSTITUTE 
Graduate Research Assistants 

Applications are invited for graduate research 
assistants in computer science, particularly in 
artificial intelligence. UTSI awards M.S. and 
Ph.D. degrees in computer science with em¬ 
phasis on applied artificial intelligence, expert 
systems and robotics. 

UTSI offers $10,250/9 months to M.S. students 
and $11,250/9 months to Ph.D. students. In addi¬ 
tion, summer appointments may be available. To 
receive an application or for further information, 
piease contact: Professor Moonis Ali, Chairman, 
Computer Science Committee, The University of 
Tennessee Space Institute, Tullahoma, TN 37388 
(phone: (615) 455-0631, ext. 283). 


SYSTEMS ANALYST 

Participates in systems and programming 
specs, develops and tests software for commu¬ 
nication systems and device drivers. Develops 
protocols and system software for modem and 
design custom Operating Systems. Supervices 
(40 percent) to programmers, BSEE or BSCS, two 
years experience and familiarity with COBOL, 
DBMS, FORTRAN, UNIX, C, PASCAL, TOPS-20. 
Salary $3077 per month. Job site and interview: 
Westlake, CA. Send this ad and resume to job 
#cw 10690, PO box 9560, Sacramento, CA 
95823-0560 not later than February 28,1987. If of¬ 
fered employment must show legal right to work 
in U.S. 


THE UNIVERSITY OF TENNESSEE 
SPACE INSTITUTE 
Faculty Positions 

Applications are tnvited for tenure track posi¬ 
tions at all levels. A Ph.D. in computer science or 
a closeiy related area and a commitment to 
research and teaching are required. Candidates 
from all areas of computer science will be con¬ 
sidered; however, preference will be given to 
candidates with expertise in artificial in¬ 
telligence or robotics. UTSI offers M.S. and Ph.D. 
degrees in computer science with emphasis on 
applied artificial intelligence, expert systems 
and robotics. 

UTSI is a multidisciplinary graduate institute of¬ 
fering degree programs and research in 
engineering, physics, applied mathematics and 
computer science. Emphasis is placed on 
research and graduate-level instruction. In addi¬ 
tion to a VAX/780 and VAX/785, a Symbolics 3600 
Lisp machine is available for research as well as 
linkages to computers at The University of Ten¬ 
nessee in Knoxville and supercomputers at 
various locations. 

Rank and salaries for these positions are open 
and commensurate with qualifications. Fringe 
benefits include group life and medical in¬ 
surance. TIAA/CREF, and reduced tuition tor 
dependents. UTSI occupies a scenic 365 acre 
lakeshore campus. 

Send a detailed resume and names of three 
references to: Professor Moonis Ali, Chairman, 
Computer Science Committee, The University of 
Tennessee Space Institute, Tullahoma, TN 
37388. (phone: (615) 455-0631, ext. 283). 

UTSI is an AA/EEO employer. 


CENTER FOR AEROSPACE SCIENCES 
Faculty Position 

Applications are Invited for an anticipated 
tenure-track faculty position in the Computer 
Science department at Assistant, Associate, or 
Professor level. Starting date is August 16,1987. 
Candidates must hold a Ph.D. in Computer 
Science or related field. Computer Science is 
one of the departments in the Center for Aero¬ 
space Sciences, a degree granting college of the 
University of North Dakota. The department of¬ 
fers an undergraduate major with 350 enrolled 
and Master’s program with 15. A Ph.D. program 
is anticipated within five years. The department 
is the principal user of a VAX 11/785 and has ac¬ 
cess to two IBM 3081’s, Perkin Elmer 8/32, 3220 
and two 3200 MPS systems and a VAX 780. Com¬ 
puter science offices and iaboratories are In the 
newest academic buiiding on campus. Salary is 
open and competitive. Benefits include TIAA- 
CREF and Blue Cross—Blue Shield. A group dis¬ 
ability insurance is also available. The candidate 
must be either a U.S. citizen or eligible for perma¬ 
nent resident status. Deadline to apply is March 
1, 1987, or until the position is filled. Send 
resume and three references to: Dr. Lonny Win- 
rich, Department of Computer Science, Box 8181 
University Station, Grand Forks, ND 58202. UND 
is an equal opportunity institution. 


AURORA UNIVERSITY 

Applications are invited for a faculty position in 
computer science with responsibilities to 
manage and teach within a new master degree 
program. Candidates should have a Ph.D. in 
computer science. AU is located within the high 
tech corridor west of Chicago. Current hardware 
support includes a VAX 11/780. Send resume, 
transcripts and three letters of reference to 
Homer E. Easley, Dean, School of Information 
Science, Aurora University, Aurora, IL 60506. 
AA/EOE 


The University invites applications for tenure- 
track computer science facuity positions begin¬ 
ning August 1987 or January 1988. A doctorate in 
computer science or computer engineering with 
teaching/research interest in OPERATING SYS¬ 
TEMS or DATA COMMUNICATIONS is desired. 
All applications, however, will be considered. In¬ 
terested individuals should fon«ard a vita and 
names of at least three references to: B. D. 
Carter, Head; Department of Computer Science; 
Mississippi State University, MS 39762. MSU is 
an Affirmative Action/Equal Opportunity 
Employer. 


PROGRAMMER, ENGINEERING 

To convert technical problem formulations to 
format processable by computer: to design and 
analyze with manager enhancements needed 
and problems found in Furniture Management 
System. To develop program specifications and 
data base/system design. To program on line, 
real time multiuser PICK based accounting 
system. To perform program and subsystem 
testing. To maintain and customize DATABASIC 
programs. 40 hours per week, $24,404 per year. 
Requires Bachelor or equivalent in Mechanical 
Engineering Technology, one year experience as 
PICK programmer. Application by resume. Con¬ 
tact nearest Job Sen/ice Center, refer to Job 
Order #C02834137. 


THE UNIVERSITY OF MICHIGAN 
Division of Computer Science and Engineering 

The Department of Electrical Engineering and 
Computer Science at The University of Michigan 
Invites applications for tenure-track positions in 
its Division of Computer Science and Engineer¬ 
ing. As the consequence of a recent merger of 
computer faculty from two departments, research 
and teaching in computer science/engineering is 
now concentrated in a single division which cur¬ 
rently has 33 faculty members. Located in a new 
building on the North Campus and with a strong 
commitment from the University, the Division is 
entering an exciting period of further expansion, 
particularly in the areas of software systems, 
hardware and architecture, artificial intelligence 
and robotics. 

Openings in the software area are at all levels 
and cover a broad range of specializations in¬ 
cluding software engineering, operating sys¬ 
tems, languages, performance evaluation, distri¬ 
buted systems, computer networks, alternate 
programming paradigms, and computer graphics. 
Strong programs are already in place in hard¬ 
ware, architecture, and fault-tolerant computing, 
and we seek further expansion with junior level 
positions in areas of parallel processing, multi¬ 
processing, computer-aided design, perfor¬ 
mance-reliability evaluation, and VLSI systems 
design. Currently active programs in artificial in¬ 
telligence include machine learning, natural lan¬ 
guage understanding, and machine vision. In Al, 
we seek at least one senior faculty member with 
fundamentai interests that underlie these ongo¬ 
ing programs. The robotics program, which has 
grown considerably in recent years, is likewise 
seeking additional faculty, particularly in areas 
of task planning, mobile robots, and sensing. All 
candidates who apply should have an interest in 
teaching and a strong research orientation. 

Send your resume and the names of at least 
three references to Professor Keki B. Irani, 
Associate Chairman, Division of Computer 
Science and Engineering, Department of Elec¬ 
trical Engineering and Computer Science, The 
University of Michigan, Ann Arbor, Ml 48109. The 
University of Michigan is an Equai Oppor¬ 
tunity/Affirmative Action Employer. 
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UNIVERSITY OF ALBERTA 
Department of Computing Science 

The Department of Computing Science is 
undergoing an extensive expansion in research 
ihitiatives. Appiications are invited for four 
tenure-track positions at the Assistant/ 
Associate Professor ievei. Responsibilities in- 
ciude research as weil as teaching at the 
graduate and undergraduate ieveis. Candidates 
from aii areas wiii be considered. Current hard¬ 
ware support includes an Amdahl 5870, a net¬ 
work of VAX 11/780’s, and well equipped 
microcomputer and workstation laboratories for 
graphics, VLSI, and Al research. Access to a 
Cyber 205 is available. Salary range is $31,612 to 
$50,630 and is commensurate with qualifica¬ 
tions and experience. Send curriculum vitae, 
names of three references, and up to three 
reprints or papers. New Ph.D.’s should also ih- 
clude a copy of their transcript. Apply to: 

Dr. Lee White, Chairman 
Department of Computing Science 
University of Alberta 
Edmonton, Alberta T6G 2H1 
Applications will be accepted until April 30, 
1987. The University of Alberta is an equal oppor¬ 
tunity employer. 


THE PENNSYLVANIA STATE UNIVERSITY 
Computer Engineering 

Applications are invited for tenure-track and 
visiting faculty positions at all levels. Can¬ 
didates from all areas of computer engineering 
(hardware and software) will be considered. The 
computer engineering program at the Pennsyl¬ 
vania State University is within the Departmeht 
of Electrical Engineering which has over 50 
faculty members, and approximately 1500 under¬ 
graduate majors, 170 graduate students. Can¬ 
didates should have a PhD in Electrioal/Com- 
puter Engineering or related areas. There are 15 
faculty members within the computer engineer-, 
ing program. Excellent instruction and research 
computing facilities are available within the 
department, college and at the university com¬ 
puting center. 

Please send your letter of application, resume, or 
inquiries, together with three references to: T. 
Feng, Computer Engineering Program, Depart¬ 
ment of Electrical Engineering, 129 Electrical 
Engineering East, Box C, The Pennsylvania State 
University, University Park, PA 16802. 

Deadline for applications is March 31,1987 or un¬ 
til suitable qualified candidates are selected. An 
Equal Opportunity/Affirmative Action Employer. 


UNIVERSITY OF WASHINGTON 

The University of Washington expects openings 
for junior and/or senior tenure-track faculty ap¬ 
pointments in Computer Science starting in the 
1987-88 academic year. A moderate teaching 
load allows time for both quality research and 
close involvement with students. As a conse¬ 
quence, we expect applicants to have a strong 
commitment to both research and teaching and 
an outstanding record of research for their level. 
A senior level applicant should have a record that 
would provide significant new research strength 
for our department. We invite applicants from all 
areas of Computer Science, quality being our 
most important selection criterion. We would 
particularly welcome applicants with research 
strength in artificial intelligence, programming 
languages and compilers, computer systems, 
and databases. In addition to the above tenure- 
track positions the department may have a 
number of visiting positions; these would re¬ 
quire both teaching and research, and could be 
for any portion of the 1987-88 academic year. 
Interested applicants should send a letter of ap¬ 
plication, a resume, and the hames of four 
references to Paul Young, Chairman, Depart¬ 
ment of Computer Science FR-35, University of 
Washington, Seattle, Washington 98195. 

The University of Washington is an Affirmative 
Action/Equal Opportunity Employer. The Ph.D. is 
required tor these positions. 


UNIVERSITY OF MARYLAND 

The Electrical Engineering Department of the 
University of Maryland College Park has open¬ 
ings for regular faculty positions in computer 
engineering. Candidates for the rank of Assis¬ 
tant Professor should have a high potential for 
both teaching and research. Candidates for the 
rank of Associate Professor and Full Professor 
should have distinguished records in research 
and a strong interest in educational programs. 
The department conducts research and educa¬ 
tional programs in all areas of computer engi¬ 
neering. Although applications in all areas of 
computer engineering will be considered, net¬ 
working, operating systems, computer security, 
architectures for parallel computing, and VLSI 
design are currently the highest priority areas for 
adding new faculty. Application, including re¬ 
sume, list of publications, list of references, 
identification of technical area for which the can¬ 
didate wishes to be considered, should be sent 
to Dr. William W. Destler, Chairman, Electrical 
Engineering Department, University of Maryland, 
College Park, Maryland 20742. The University of 
Maryland is an equal opportunity, affirmative ac¬ 
tion employer. 


UNIVERSITY OF CALIFORNIA, RIVERSIDE 

Applications are invited for a tenure-track or 
tenure position in Computer Science beginning 
Fall 1987. Candidates must have demonstrated 
excellence in research and teaching. Research 
specialties in all areas of Computer Science will 
be considered but we are particularly Interested 
in research areas in Computer Systems or Com¬ 
puter Methodology and Applications. The posi¬ 
tion is open as to the level of appointment. 
Applicants should send a curriculum vitae and 
see that at least three letters of recommendation 

Professor Theodore J. Barth, Chair 
Computer Science Search Committee 
Department of Mathematics and Computer 
Science 

University of California 
Riverside, CA 92521 

University of California, Riverside, is an Affir¬ 
mative Action/Equal Opportunity Employer. 


CLEMSON UNIVERSITY 
Computer Engineering 

ELECTRICAL and COMPUTER ENGINEERING 
at CLEMSON UNIVERSITY is seeking applicants 
for tenure-track and visiting positions in Com¬ 
puter Engineering program offering BS, MS and 
PhD degrees. All areas of computer engineerihg 
are of interest, with special emphasis on 
distributed system software and hardware, com¬ 
puter networkihg and computer architecture. 
Positiohs in Electrical Engineering degree pro¬ 
gram also available, with areas of specialization 
including microelectronics, reliability, robotics, 
communications, signal processing, elec¬ 
tromagnetics and power. 

Applicants should have a Ph.D. and a strong in¬ 
terest in teaching and research. Research 
Associate positions (BS,MS) are also available. 
Send resumes to Dr. A. Wayne Bennett, E&CE 
Department, Clemson University, Clemson, SC 
29634-0915. Clemson is an Equal Opportunity/Af¬ 
firmative Action Employer. 


STATE UNIVERSITY OF NEW YORK 
AT BUFFALO 

The Department of Computer Science is seeking 
faculty at the level of Assistant Professor to 
begin Fall, 1987. Applicants must have a Ph.D. in 
Computer Science, or a related field, and 
superior research ability. 

The University at Buffalo is the largest public 
university in New York and New England, with 
approximately 26,000 students enrolled in 93 
undergraduate, 101 master’s, and 94 doctoral 
programs, including law, medical, and business 
schools. 

The Department offers BA, BS, MS, and PhD 
degrees, with controlled undergraduate enroll¬ 
ment. Departmental computing facilities include 
a VAX 11/780, two VAX-11/750s, six SUNs, six lisp 
machines and several image processing/graph¬ 
ics systems. Present research areas ihclude ar¬ 
tificial intelligence, computer vision, numerical 
analysis, parallel algorithms, theory of computa¬ 
tion, VLSI, etc. The Departmeht Is expanding, 
with additional faculty lines committed annually. 
Salaries are extremely competitive. 

Resumes and names of four references should 
be directed to: Prof. Sargur N. Srihari, Chairman 
of Search Committee, Department of Computer 
Science, 226 Bell Hall, SUNY at Buffalo, Buffalo, 
NY 14260 (CSnet: srihari® buffalo). SUNY is an 
affirmative action/equal opportunity employer. 


NAVAL POSTGRADUATE SCHOOL 
Monterey, CA 

Position Announcement in Computer Science 

The Department of Computer Science has im¬ 
mediate openings for faculty positions at all 
levels in the areas of Artificial Intelligence and 
Computer Architecture. An applicant should 
have a PhD in Computer Science or a related 
field and have a strong interest in both graduate 
teaching and research. Senior applicants must 
have distinguished research records. Appoint¬ 
ments can begin at any time during the year. 
The Department offers MS and PhD degrees in 
Computer Science supported by well-equipped 
instructional/research facilities and a full-time 
technical staff. The faculty normally teach for 
two quarters and conduct full-time research sup¬ 
ported by major research programs during the 
other two quarters. 

Please send a detailed resume and three letters 
of reference to: Professor Vincent Lum, Chair, 
Computer Sciehce Departmeht (Code 52), Naval 
Postgraduate School, Mohterey, CA 93943, tele¬ 
phone (408) 646-2449. NPS IS AN EQUAL OP¬ 
PORTUNITY/AFFIRMATIVE ACTION EM¬ 
PLOYER. 


LOUISIANA STATE UNIVERSITY 
Faculty Openings 

The Department of Electrical and Computer 
Engineering at LSU invites applications for 
tenure-track and visiting faculty positions 
available August 1987 in all areas of computer 
engineering, including microprocessors, distrib¬ 
uted processing systems and special purpose 
architectures. A PhD or equivalent and potential 
for excellence in teaching and research are hec- 
essary. Rank is open. Salary is competitive and 
commensurate with qualifications and experi¬ 
ence. Release time and resources are provided 
in order to enhance the development of a quality 
research program. Opportunities for summer 
support are available. Send resume, names of 
three references and a statement of teaching 
and research interests to: Alan H. Marshak, 
Chairman, Electrical and Computer Engineering, 
Louisiana State University, Baton Rouge, LA 
70803-5901. LSU is an Equal Opportunity 
Employer. 
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OHIO STATE UNIVERSITY 
Department ol Computer and 
Information Science 

Applications are invited tor faculty positions at 
aii leveis. A Ph.D. in computer science or a close¬ 
ly related field is required. Of special interest are 
candidates in the areas of artificial intelligence, 
computr graphics, data bases, parallel and dis¬ 
tributed computing, software engineering, and 
VLSI design. Special research support packages 
are negotiable for highly qualified candidates. 
Research computing facilities within the Depart¬ 
ment include DEC 20/60, VAX 11/780, IBM 4341, 
AT&T 3B2, Xerox Lisp and XDE machines. Sun 
and HP workstations, and several experimental 
multi-computers (Intel Hypercube, BBN Butter¬ 
fly, etc.). In addition to the University’s com¬ 
puting facilities (IBM 3081-D, etc.) the de¬ 
partment also has access to national networks 
including ARPANET and CSNET. 

To apply, please send application and resume, 
including a statement of research and teaching 
interests and he names and address of at least 
three references, to Prof. Ming T. (Mike) Liu, 
chairman of Faculty Search Committee, Depart¬ 
ment of Computer and Information Science, The 
Ohio State University, 2036 Neil Avenue, Colum¬ 
bus, Ohio 43210-1277 (CSNET/ARPANET:LIU @ 
Ohio-State.) The Ohio State University is an 
equal opporunity/affirmative action employer. 


THE UNIVERSITY OF TEXAS AT ARLINGTON 

The Department of Computer Science Engineer¬ 
ing (CSE) at the University of Texas at Arlington 
(UTA) invites your application for tenure-track or 
visiting faculty positions in all areas of computer 
science and computer engineering. Rank is 
open. An earned doctorate or equivalent and 
commitment to teaching and scholarly research 
is required. Openings are expected for June, or 
September 1987. Our department offers bacca¬ 
laureate, masters, and doctoral programs. Ex¬ 
cellent computing facilities are available in¬ 
cluding personal computers in each CSE faculty 
office. UTA is in the Dallas/Fort Worth metropoli¬ 
tan area near a large concentration of high tech¬ 
nology industries. Interested persons should 
send a resume to Professor Bill D. Carroll, Pro¬ 
fessor and Chairman, Computer Science Engi¬ 
neering Department, P.O. Box 19015, The Univer¬ 
sity of Texas at Arlington, Arlington, TX 76019. 
Phone (817) 273-3785. 

The University of Texas at Arlington is an Equal 
Opportunity Affirmative Action Employer. 


BUCKNELL UNIVERSITY 

Bucknell University invites applications for 
tenure track faculty positions at the assistant or 
associate professor level. A Ph.D in Computer 
Science or related discipline is normally re¬ 
quired. Applicants should demonstrate both an 
interest in and a promise of developing excel¬ 
lence in teaching and research. All research 
areas considered. First year research and sum¬ 
mer support funds available. 

The computing environment includes VAX 
11/780 VMS, VAX 11/750 UNIX, Sun3 and Apollo 
workstations, DG Eclipse network lab, HP In¬ 
strumentation lab, VAX Station II, and a Honey¬ 
well Level 66 DPS mainframe. 

Please send a curriculum vitae and the names of 
three references to Gary Haggard, Dept, of 
Comp. Sci., Bucknell Univ., Lewisburg, PA 17837 
or HAGGARD@BUCKNELL.BITNET. Applica¬ 
tions will be considered beginning November 15. 
Appointments for January 1987 are possible. 
Applications from women and members of mi¬ 
nority groups are encouraged. 


THE JOHNS HOPKINS UNIVERSITY 
Department of Computer Science 

The Johns Hopkins University has formed an in¬ 
dependent Department of Computer Science 
within the G.W.C. Whiting School of Engineer¬ 
ing. During the next five years, a faculty of ap¬ 
proximately sixteen will be developed to repre¬ 
sent the University in the field of computer 
science and engineering according to Hopkins' 
traditional standards of research and teaching of 
the highest rank. Construction of a new building 
to house the department will begin during the 
fall of 1986. Additional faculty are sought at all 
professorial levels with research and teaching 
interests in artificial intelligence, computer vi¬ 
sion, graphics, programming languages, sys¬ 
tems (especially parallel and distributed com¬ 
puting and networks), and theory. Senior can¬ 
didates should have an outstanding record of 
research achievement; junior candidates should 
exhibit superior research potential. Although the 
teaching load is moderate, genuine commitment 
to teaching excellent graduates and under¬ 
graduates is also necessary. 

Applicants should send a resume and the names 
of at least three references to: Professor Gerald 
M. Masson, Department of Computer Science, 
The Johns Hopkins University, Baltimore, MD 
21218 [phone: (301) 338-8775]. The Johns 
Hopkins University is an equal opportunity, affir¬ 
mative action employer. 


GEORGE WASHINGTON UNIVERSITY 
Tenure-Track Faculty Positions 

The Department of Electrical Engineering and 
Computer Science invites applications for 
tenure-track faculty positions. We particularly 
seek persons active in the areas of Computer 
Science and Communications. Candidates 
should have an earned doctorate and research 
experience, with an interest in both teaching and 
research. Ability to attract research grants and 
contracts for support of faculty and student as¬ 
sistants is valued. The George Washington Uni¬ 
versity is located in the center of Washington, 
DC. This metropolitan area sustains the second 
largest concentration of research and develop¬ 
ment activity in the United States which creates 
a continuing demand for rigorously trained engi¬ 
neers as well as broad research opportunities. 
Our department is the largest department in the 
School of Engineering and Applied Science with 
33 full-time faculty, and a large graduate and 
undergraduate student body. The department 
has an annual research budget of close to $1 
million. Send Curriculum Vitae, list of publica¬ 
tions and references, to: 

Professor Roger H. Lang, Chairman 
Department of Electrical Engineering and 
Computer Science 

School of Engineering & Applied Science 
THE GEORGE WASHINGTON UNIVERSITY 
Washington, DC 20052 

The University is an affirmative action/equal op¬ 
portunity employer. 


WESTERN WASHINGTON UNIVERSITY 

Funding permitting. Computer Science will have 
two tenure-track openings for the academic year 
starting Sept., 1987. Ph.D. in Computer Science 
or closely related field is required. There is need 
to staff the mainline undergraduate courses and 
to strengthen the masters’ program. 

For more information, please contact James 
Johnson, Chairman, Computer Science Dept., 
Western Washington University, Bellingham, 
Washington 98225; CSNET address: Johnson 
%wwu@csnet-relay.arpa WWU is an EO/AA 
employer. 


THE PENNSYLVANIA STATE UNIVERSITY 

The Department of Computer Science is seeking 
qualified candidates for expected tenure track 
and visiting positions. Applications in all areas 
of computer science will be considered, with 
applicants in the areas'of architecture, artificial 
intelligence, databases, networking, operating 
systems, and programming languages especial¬ 
ly desired. Salary and rank will be commensurate 
with experience. Applicants must have com¬ 
pleted all requirements for the Ph.D. degree in 
computer science or a closely related area 
before assuming duties. Excellence in research 
and teaching are required. Candidates for senior 
positions must have an established research 
reputation supported by a substantial record of 
publications. Openings are expected tor January 
1,1987 and September 1987. 

The Department of Computer Science maintains 
a Computer Systems Laboratory and several 
machines for research and graduate instruction, 
including two VAX 11/780’s, a VAX 11/750 and 
two PDP 11/34’s (all running UNIX). 

All applications should be received by March 31, 
1987. Applications will be considered until suit¬ 
able candidates can be identified. 

Please send resume and the names of three or 
more references to: Chair, Search Committee, 
The Pennsylvania State University, Department 
of Computer Science, Box D, Whitmore Labora¬ 
tory, University Park, PA 16802. An Affirmative 
Action/Equal Opportunity Employer. 
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- THE CONFERENCE - 

The 1987 INTERNATIONAL CONFERENCE ON COMPUTER-AIDED DESIGN will be held NOVEMBER 9-12, 1987. 
The Conference is oriented towards Electrical Engineering CAD professionals, concentrating on CAD for Electronic Circuit 
Design. 


- AREAS OF INTEREST 

Papers on (but not limited to) the following topics are invited: 


• Simulation: 

• Layout: 

• Test: 

• Systems: 


Functional, Logic, Timing, Circuit, Device and Process Simulation, Modeling. 

Placement, Routing, Floor Planning, Interactive and Symbolic Layout, Circuit Extraction, Design Rule 
Checking. 

Test Pattern Generation, Testability, Built-in-Test, Fault Simulation. 

Design Synthesis, Silicon Compilers, Expert Systems, Tool Integration, Data Base Management, Hardware 
Acceleration, CAD Systems. 


All papers should be suitable for a 25 minute presentation, and must not have been previously published. 


- AUTHOR INFORMATION - 

Authors should submit 12 COPIES of both a I-paragraph abstract and a more detailed description not to exceed 1500 words or six pagc.s 
(double-spaced). Excessively long submissions may be returned to the authors. 

Format: 

The 1-PARAGRAPH ABSTRACT, typed on one separate page, should clearly and precisely state what is new and point out the significant 
results. Succinctness is required since this paragraph may be included in the Advance Program. 

An author must somehow in the 1500 WORD DESCRIPTION objectively address the question why the proposed contribution is superior to 
prior work or what is the significance of the contribution if breaking new ground. Demonstration of superiority in algorithms and strategics 
with heuristics is required through a description of the programming implementation and application to "real" problems. Additional 
mathematical proofs are welcome. The contribution should address an area of current technical interest to the CAD professional. A clear 
description of the new contribution, status of the work and significant examples and results should be given. References, figures and tables 
are not counted as part of the 1500 words. 

Submissions should include, on the first page: the title of the paper, full author names and their affiliations, complete return address and 
telephone number (with the individual to whom all communications should be addressed clearly identified.) In giving your return address, 
please consider that the communications for paper acceptance and mailing of the author kit occur in the month of July. 

- DATES - 

• Submissions should be received no later than May 1, 1987. 

Send to: lCCAD-87 Secretary, Mentor Graphics Corp., 

1940 Zanker Road. San Jose, CA 95112, Tel: (408) 436-1500. 

• Notification of acceptance will be JULY 1,' 1987. 

• Final version of Digest of Technical Papers will be due AUGUST 14, 1987. 














First International Workshop on 
Computer-Aided Software Engineering 
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Cambridge, Massachusetts 
May 27-29, 1987 


CALL FOR P 


The field of Computer-Aided 
Software Engineering (CASE) 
has recently emerged as a 
commercially-viable 
widespread application of 
software engineering 
techniques and computer 
technology to information 
systems development. With the 
rapid development of computer 
technology, it is essential to 
look ahead at the needs of 
users and organizations, the 
enabling technologies, and the 
growth of information systems 
engineering techniques. 

CASE '87 will provide a forum 
for solid, detailed exchange of 
Ideas among key practitioners, 
researchers, developers, and 
leading-edge users in the field, 
and will result in meaningful 
goals for the advancement of 
CASE technology in the next 
five years. 

Working groups will review the 
current state-of-the-art, discuss 
present research directions, 
and consider future 
requirements in five topic 
areas: 


■ Methods for Information 
Systems Development; 

Application Domains and Automatable 
Methods: Evolution of Methods: 
Convergence of Data- and 
Process-Oriented Methods: Information 
Engineering: Distinction between 
Real-TimelEmbedded-System and 
Commercial D.P. Approaches: Methods 
for EngineeringIScientific Development: 
New Domains: Object-Oriented 
Methods, Distributed Systems, 
End-User Computing, Expert Systems. 

■ Application of Enabling 
Technologies: 

Al: Expert Systems: Knowledge-Based 
Tools: Computer Conferencing: 
Database: Information Resource 
Directories: 4GLs: Graphics: Ada 
Technology: Reusable Components: 
Modeling and Simulation: Role of 
International Standards. 


m User Working 
Environment: 

User Interfaces: Human Factors: 
Human-Computer Interaction: 
Distributed Systems: Work Sharing: 
Support of Group Work: Integration of 
Diverse Tools and Software 
Environments: APSE: Program Support 
Environments: Extensibility. 

■ Hardware Environment 
and Tools: 

Workstation Environments: Networks 
and Data Sharing: Processor 
Capabilities: Peripherals Technology: 
Cooperative Processing. 

■ Impact of Programming 
Language Technology: 

Evolution of Language Development: 
Very-High-Levet Languages: 
Requirements Languages: 
Domain-Specific Languages: 
Object-Oriented Programming. 


P E R S 


Attendance is limited. 
Prospective attendees should 
submit a position paper (1 to 3 
pages) or extended abstract on 
future directions of CASE 
technology related to one or 
more of the topic areas, 
by March 18, 1987 

Longer papers are Invited for 
presentation and subsequent 
publication in proceedings. 

Machine-readable submissions 
are preferred. Call for Tools 
Fair Information. 

Submit position papers to: 

CASE '87 

do Elliot Chikofsky 
Index Technology Corporation 
101 Main Street 
Cambridge, MA 02142 

(617) 491-2100 ext. 8000 

CSNET: BurtR@NUHUB.ACS. 

Northeastern.EDU 


Sponsored by: 

Index Technology Corporation 
In Conjunction With: 

Purdue University 
Northeastern University 
Greater Boston Chapter ACM 
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